[dpdk-users] Issue with UDP based fragmented packets on Azure cloud

[Stephen Hemminger]

On Thu, 27 May 2021 15:40:57 +0000
Raslan Darawsheh <rasland at nvidia.com> wrote:

> Hi,
> 
> > -----Original Message-----
> > From: users <users-bounces at dpdk.org> On Behalf Of madhukar mythri
> > Sent: Thursday, May 27, 2021 5:58 PM
> > To: users at 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.