On Thu, 27 May 2021 15:40:57 +0000 Raslan Darawsheh <[email protected]> wrote:
> Hi, > > > -----Original Message----- > > From: users <[email protected]> On Behalf Of madhukar mythri > > Sent: Thursday, May 27, 2021 5:58 PM > > To: [email protected] > > Subject: [dpdk-users] Issue with UDP based fragmented packets on Azure > > cloud > > > > Hi, > > > > We are facing issue with UDP/IP based fragmented packets on Azure cloud > > platform with Accelerated-Network enabled ports. > > > > UDP fragmented Rx packets were able to receive well on media ports. But, > > when two fragmented packet received, first fragment is received on Queue- > > 0 > > and second fragment is received on Queue-1. Ideally all the fragments(of > > single large packet) should be received single queue based on RSS, so that > > we can re-assemble as single pkt and process it, which is working well in > > other platforms on KVM hyper-visors(with I40evf NIC’s). > > > > I think, the as per RSS hash cacluation all the fragmented pkts should > > reach on single-queue(because the 5-tuple hash value will be same), but > > this is not happening in-case of Azue VM's Why ? > > > > Does anybody faced similar issue, please let me know your suggestion. > I guess it depends on the fragments themselves, > If your first fragment contains a UDP header (the first frag in the list) > then the RSS hash will be on the full 5 tuble > Src/dst IP and src/dst udp > But, for the other frags you'll not get src/dst udp since they are not > present in the pkt. > I guess you should be using only RSS On IP header to make all frags go to the > same queue. > > Yes, and this is not unique to Azure or even the DPDK. Fragmented packets do not have enough information (no UDP header in second fragment) to do L4 RSS.
