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.
> ===========================================================================
> ====
prev 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 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).