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

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

[madhukar mythri]

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.

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

[Raslan Darawsheh]

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

Re: [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@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.

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

[Muhammad Zain-ul-Abideen]

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.
>
>

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

[madhukar mythri]

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.
>>
>>