DPDK patches and discussions
 help / color / mirror / Atom feed
From: "François-Frédéric Ozog" <ff@ozog.com>
To: "'Prashant Upadhyaya'" <prashant.upadhyaya@aricent.com>,
	'吴亚东' <ydwoo0722@gmail.com>,
	"'Thomas Monjalon'" <thomas.monjalon@6wind.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] generic load balancing
Date: Fri, 6 Dec 2013 08:53:21 +0100	[thread overview]
Message-ID: <012001cef258$3c77a180$b566e480$@com> (raw)
In-Reply-To: <C7CE7EEF248E2B48BBA63D0ABEEE700C5353AEF9C4@GUREXMB01.ASIAN.AD.ARICENT.COM>

Can we (as a community) be leading the way for the NIC vendors?

I mean, a few years ago I had the discussion with Chelsio to solve MPLS and GTP load balancing.
They were happy to integrate the "requirements" in the roadmap....

So could we build a list of such "requirements" and publish it? NIC vendors are looking ways to differentiate from one another, so I assume this may help us get what we want.

In addition to the NIC requirements we may polish an API to control those features in a standard way from DPDK.


François-Frédéric


> -----Message d'origine-----
> De : dev [mailto:dev-bounces@dpdk.org] De la part de Prashant Upadhyaya
> Envoyé : vendredi 6 décembre 2013 05:04
> À : 吴亚东; Thomas Monjalon
> Cc : dev@dpdk.org
> Objet : Re: [dpdk-dev] generic load balancing
> 
> Hi,
> 
> Regarding this point –
> 
> If intel supports round robin distribution of packets in the same flow,
> Intel needs to provide some way like Cavium's SSO(tag switch) to maintain
> packet order in the same flow. And it is hard to do so because intel's cpu
> and nic are decoupled
> 
> My main submission is – I understand there are issues like the above and
> ooo stuff you pointed out.
> But that is for the usecase implementer to solve in software logic. The
> equivalent of tag switch can be attempted to be developed in the software
> if the usecase so desires.
> But atleast ‘give’ the facility in the NIC to fan out on round robin on
> queues.
> Somehow we are trying to find out reasons why we should not have it.
> I am saying, give it in the NIC and let people use it in innovative ways.
> People who don’t want to use it can always have the choice to not use it.
> 
> Regards
> -Prashant
> 
> 
> From: 吴亚东 [mailto:ydwoo0722@gmail.com]
> Sent: Friday, December 06, 2013 7:47 AM
> To: Thomas Monjalon
> Cc: Michael Quicquaro; Prashant Upadhyaya; dev@dpdk.org
> Subject: Re: [dpdk-dev] generic load balancing
> 
> RSS is a way to distribute packets to multi cores while packets order in
> the same flow still get maintained.
> 
> Round robin distribution of packets may cause ooo(out of order) of packets
> in the same flow.
> We also meet this problem in ipsec vpn case.
> The tunneled packets are rss to the same queue if they are on the same
> tunnel.
> But if we dispatch the packets to the other cores to process, ooo packets
> may occur and tcp performance may be greatly hurt.
> 
> If you enable rss on udp packets and some udp packets are ip fragmented,
> rss of udp fragments(hash only calculated from ip addr) may be different
> fom rss of udp non-fragment packets(hash with information of udp ports),
> ooo may occur too.
> So in kernel driver disables udp rss by default.
> 
> If intel supports round robin distribution of packets in the same flow,
> Intel needs to provide some way like Cavium's SSO(tag switch) to maintain
> packet order in the same flow. And it is hard to do so because intel's cpu
> and nic are decoupled.
> 
> 
> 
> 
> 2013/12/6 Thomas Monjalon
> <thomas.monjalon@6wind.com<mailto:thomas.monjalon@6wind.com>>
> Hello,
> 
> 05/12/2013 16:42, Michael Quicquaro :
> > This is a good discussion and I hope Intel can see and benefit from it.
> Don't forget that this project is Open Source.
> So you can submit your patches for review.
> 
> Thanks for participating
> --
> Thomas
> 
> 
> 
> 
> 
> ===========================================================================
> ====
> Please refer to http://www.aricent.com/legal/email_disclaimer.html
> for important disclosures regarding this electronic communication.
> ===========================================================================
> ====

      reply	other threads:[~2013-12-06  7:53 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-04 17:53 Michael Quicquaro
2013-12-04 20:48 ` elevran
2013-12-04 21:04 ` François-Frédéric Ozog
2013-12-05  4:31   ` Prashant Upadhyaya
2013-12-05  4:54     ` Stephen Hemminger
2013-12-05  5:29       ` Prashant Upadhyaya
2013-12-05  7:44         ` Benson, Bryan
2013-12-05 14:16           ` Prashant Upadhyaya
2013-12-05 18:33             ` Benson, Bryan
2013-12-05  8:45         ` François-Frédéric Ozog
2013-12-05 14:29           ` Prashant Upadhyaya
2013-12-05 15:42             ` Michael Quicquaro
2013-12-05 16:21               ` Thomas Monjalon
2013-12-06  2:16                 ` 吴亚东
2013-12-06  4:03                   ` Prashant Upadhyaya
2013-12-06  7:53                     ` François-Frédéric Ozog [this message]

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to='012001cef258$3c77a180$b566e480$@com' \
    --to=ff@ozog.com \
    --cc=dev@dpdk.org \
    --cc=prashant.upadhyaya@aricent.com \
    --cc=thomas.monjalon@6wind.com \
    --cc=ydwoo0722@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).