All of lore.kernel.org
 help / color / mirror / Atom feed
From: "François-Frédéric Ozog" <ff-SpBG2i6TTxU@public.gmane.org>
To: "'Prashant Upadhyaya'"
	<prashant.upadhyaya-pccXkzZloW5BDgjK7y7TUQ@public.gmane.org>,
	'吴亚东' <ydwoo0722-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	"'Thomas Monjalon'"
	<thomas.monjalon-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
Cc: dev-VfR2kkLFssw@public.gmane.org
Subject: Re: 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-2zbAqoMm/rLQX//ci7WS+53eMK7GYZcrXYFosVITYPE@public.gmane.org>

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-VfR2kkLFssw@public.gmane.org] De la part de Prashant Upadhyaya
> Envoyé : vendredi 6 décembre 2013 05:04
> À : 吴亚东; Thomas Monjalon
> Cc : dev-VfR2kkLFssw@public.gmane.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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
> Sent: Friday, December 06, 2013 7:47 AM
> To: Thomas Monjalon
> Cc: Michael Quicquaro; Prashant Upadhyaya; dev-VfR2kkLFssw@public.gmane.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-pdR9zngts4EAvxtiuMwx3w@public.gmane.org<mailto:thomas.monjalon-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>>
> 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.
> ===========================================================================
> ====

      parent 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 generic load balancing Michael Quicquaro
     [not found] ` <CAAD-K94YUY6aUPzvJyqJ7w4W2_81d0Fq7EvwJ1xKOzzd3Ld4Lw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-12-04 20:48   ` elevran
2013-12-04 21:04   ` François-Frédéric Ozog
2013-12-05  4:31     ` Prashant Upadhyaya
     [not found]       ` <C7CE7EEF248E2B48BBA63D0ABEEE700C5353AEF76F-2zbAqoMm/rLQX//ci7WS+53eMK7GYZcrXYFosVITYPE@public.gmane.org>
2013-12-05  4:54         ` Stephen Hemminger
     [not found]           ` <CAOaVG16OSgtUOTiv6nqOfuz7MgDP+Hygqv7hEKUMxMaFctnCpg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-12-05  5:29             ` Prashant Upadhyaya
     [not found]               ` <C7CE7EEF248E2B48BBA63D0ABEEE700C5353AEF790-2zbAqoMm/rLQX//ci7WS+53eMK7GYZcrXYFosVITYPE@public.gmane.org>
2013-12-05  7:44                 ` Benson, Bryan
     [not found]                   ` <eexymb17q9xfuyslcxlpfvhi.1386229465261-2ueSQiBKiTY7tOexoI0I+QC/G2K4zDHf@public.gmane.org>
2013-12-05 14:16                     ` Prashant Upadhyaya
     [not found]                       ` <C7CE7EEF248E2B48BBA63D0ABEEE700C5353AEF969-2zbAqoMm/rLQX//ci7WS+53eMK7GYZcrXYFosVITYPE@public.gmane.org>
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
     [not found]                     ` <C7CE7EEF248E2B48BBA63D0ABEEE700C5353AEF970-2zbAqoMm/rLQX//ci7WS+53eMK7GYZcrXYFosVITYPE@public.gmane.org>
2013-12-05 15:42                       ` Michael Quicquaro
     [not found]                         ` <CAAD-K95OAw2zAhW5J16CD79HBK4dkeofG1CVudyMBx2SoVC48Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-12-05 16:21                           ` Thomas Monjalon
     [not found]                             ` <201312051721.51070.thomas.monjalon-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
2013-12-06  2:16                               ` 吴亚东
     [not found]                                 ` <CAGbq_NweTxOfzY2twfkQ8SjJF0=7jMrk=R=Tnw-j5MZkdN7bvg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-12-06  4:03                                   ` Prashant Upadhyaya
     [not found]                                     ` <C7CE7EEF248E2B48BBA63D0ABEEE700C5353AEF9C4-2zbAqoMm/rLQX//ci7WS+53eMK7GYZcrXYFosVITYPE@public.gmane.org>
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-spbg2i6ttxu@public.gmane.org \
    --cc=dev-VfR2kkLFssw@public.gmane.org \
    --cc=prashant.upadhyaya-pccXkzZloW5BDgjK7y7TUQ@public.gmane.org \
    --cc=thomas.monjalon-pdR9zngts4EAvxtiuMwx3w@public.gmane.org \
    --cc=ydwoo0722-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.