DPDK usage discussions
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: Raslan Darawsheh <rasland@nvidia.com>
Cc: madhukar mythri <madhukar.mythri@gmail.com>,
	"users@dpdk.org" <users@dpdk.org>
Subject: Re: [dpdk-users] Issue with UDP based fragmented packets on Azure cloud
Date: Thu, 27 May 2021 12:57:03 -0700
Message-ID: <20210527125703.059eeead@hermes.local> (raw)
In-Reply-To: <DM4PR12MB5054ADA6406B1C90F6ACE5C5CF239@DM4PR12MB5054.namprd12.prod.outlook.com>

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.

  reply	other threads:[~2021-05-27 19:57 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-27 14:57 madhukar mythri
2021-05-27 15:40 ` Raslan Darawsheh
2021-05-27 19:57   ` Stephen Hemminger [this message]
2021-05-28  6:51     ` Muhammad Zain-ul-Abideen
2021-05-28 10:24       ` madhukar mythri

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210527125703.059eeead@hermes.local \
    --to=stephen@networkplumber.org \
    --cc=madhukar.mythri@gmail.com \
    --cc=rasland@nvidia.com \
    --cc=users@dpdk.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

DPDK usage discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/users/0 users/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 users users/ https://inbox.dpdk.org/users \
	public-inbox-index users

Example config snippet for mirrors.
Newsgroup available over NNTP:

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git