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. Thanks, Madhukar.
Hi, > -----Original Message----- > From: users <users-bounces@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. > > Thanks, > Madhukar. Kindest regards, Raslan Darawsheh
On Thu, 27 May 2021 15:40:57 +0000
Raslan Darawsheh <rasland@nvidia.com> wrote:
> Hi,
>
> > -----Original Message-----
> > From: users <users-bounces@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.
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 <stephen@networkplumber.org>
wrote:
> On Thu, 27 May 2021 15:40:57 +0000
> Raslan Darawsheh <rasland@nvidia.com> wrote:
>
> > Hi,
> >
> > > -----Original Message-----
> > > From: users <users-bounces@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.
>
>
Hi Raslan and stephen, Thanks for your response. Yes, i had done RSS for IP layer only as follows: portConf.rx_adv_conf.rss_conf.rss_hf = (ETH_RSS_IP ); // | ETH_RSS_TCP| ETH_RSS_UDP); Commented out the RSS for UDP/TCP flags. But, still im facing the same issue, the fragments pkts are not coming on to the single queue, not sure why ? Here we use DPDK is 20.11. The interfaces are coming up with Failsafe PMD with 2 queues. I had seen issue related to Azure UDP fragmentation on the following link: https://github.com/MicrosoftDocs/azure-docs/issues/29476 So, any known limitations. Regards, Madhuker. On Fri, May 28, 2021 at 12:22 PM Muhammad Zain-ul-Abideen < zain2294@gmail.com> wrote: > 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 < > stephen@networkplumber.org> wrote: > >> On Thu, 27 May 2021 15:40:57 +0000 >> Raslan Darawsheh <rasland@nvidia.com> wrote: >> >> > Hi, >> > >> > > -----Original Message----- >> > > From: users <users-bounces@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. >> >>