I wonder is there any way to bypass RSS for some IP flag values like mf, or frag_offset
On Fri, May 28, 2021, 12:57 AM Stephen Hemminger <step...@networkplumber.org> wrote: > On Thu, 27 May 2021 15:40:57 +0000 > Raslan Darawsheh <rasl...@nvidia.com> wrote: > > > Hi, > > > > > -----Original Message----- > > > From: users <users-boun...@dpdk.org> On Behalf Of madhukar mythri > > > Sent: Thursday, May 27, 2021 5:58 PM > > > To: users@dpdk.org > > > 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. > >
