From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mo1.mail-out.ovh.net (2.mo1.mail-out.ovh.net [178.32.119.250]) by dpdk.org (Postfix) with ESMTP id 801B0156 for ; Thu, 5 Dec 2013 09:46:04 +0100 (CET) Received: from mail406.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo1.mail-out.ovh.net (Postfix) with SMTP id C3723FFAE37 for ; Thu, 5 Dec 2013 09:50:02 +0100 (CET) Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 5 Dec 2013 10:51:13 +0200 Received: from lneuilly-152-23-9-75.w193-252.abo.wanadoo.fr (HELO pcdeff) (ff@ozog.com@193.252.40.75) by ns0.ovh.net with SMTP; 5 Dec 2013 10:51:12 +0200 From: =?iso-8859-1?Q?Fran=E7ois-Fr=E9d=E9ric_Ozog?= To: "'Prashant Upadhyaya'" References: <03f701cef134$7e564720$7b02d560$@com> In-Reply-To: Date: Thu, 5 Dec 2013 09:45:39 +0100 Message-ID: <003901cef196$604e5da0$20eb18e0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7xdhmdU7sKtZzHQ/21UCnTI6UAzAABMGwQAAaZqdA= Content-Language: fr X-Ovh-Tracer-Id: 4503599629192779993 X-Ovh-Remote: 193.252.40.75 (lneuilly-152-23-9-75.w193-252.abo.wanadoo.fr) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-OVH-SPAMSTATE: OK X-OVH-SPAMSCORE: -100 X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeeiledrkeeiucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd X-Spam-Check: DONE|U 0.5/N X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeeiledrkeeiucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd Cc: dev@dpdk.org Subject: Re: [dpdk-dev] generic load balancing X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 08:46:04 -0000 Hi, If the traffic you manage is above MPLS or GTP encapsulations, then you = can use cards that provide flexible hash functions. Chelsio cxgb5 provides combination of "offset", length and tuple that may help.=20 The only reason I would have loved to get a pure round robin feature was = to pass certain "Breaking Point" (http://www.ixiacom.com/breakingpoint) = tests where the traffic issue was multicast from a single source... But that = is not real life traffic. If you could share the use case... Fran=E7ois-Fr=E9d=E9ric > -----Message d'origine----- > De=A0: Prashant Upadhyaya [mailto:prashant.upadhyaya@aricent.com] > Envoy=E9=A0: jeudi 5 d=E9cembre 2013 06:30 > =C0=A0: Stephen Hemminger > Cc=A0: Fran=E7ois-Fr=E9d=E9ric Ozog; Michael Quicquaro; dev@dpdk.org > Objet=A0: RE: [dpdk-dev] generic load balancing >=20 > Hi Stepher, >=20 > The awfulness depends upon the 'usecase' > I have eg. a usecase where I want this roundrobin behaviour. >=20 > I just want the NIC to give me a facility to use this. >=20 > Regards > -Prashant >=20 >=20 > -----Original Message----- > From: Stephen Hemminger [mailto:stephen@networkplumber.org] > Sent: Thursday, December 05, 2013 10:25 AM > To: Prashant Upadhyaya > Cc: Fran=E7ois-Fr=E9d=E9ric Ozog; Michael Quicquaro; dev@dpdk.org > Subject: Re: [dpdk-dev] generic load balancing >=20 > Round robin would actually be awful for any protocol because it would cause > out of order packets. > That is why flow based algorithms like flow director and RSS work much > better. >=20 > On Wed, Dec 4, 2013 at 8:31 PM, Prashant Upadhyaya > wrote: > > Hi, > > > > It's a real pity that Intel 82599 NIC (and possibly others) don't = have a > simple round robin scheduling of packets on the configured queues. > > > > I have requested Intel earlier, and using this forum requesting = again -- > please please put this facility in the NIC that if I drop N queues = there > and configure the NIC for some round robin scheduling on queues, then = NIC > should simply put the received packets one by one on queue 1, then on > queue2,....,then on queueN, and then back on queue 1. > > The above is very useful in lot of load balancing cases. > > > > Regards > > -Prashant > > > > > > -----Original Message----- > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of = Fran=E7ois-Fr=E9d=E9ric > > Ozog > > Sent: Thursday, December 05, 2013 2:35 AM > > To: 'Michael Quicquaro' > > Cc: dev@dpdk.org > > Subject: Re: [dpdk-dev] generic load balancing > > > > Hi, > > > > As far as I can tell, this is really hardware dependent. Some hash > functions allow uplink and downlink packets of the same "session" to = go to > the same queue (I know Chelsio can do this). > > > > For the Intel card, you may find what you want in: > > = http://www.intel.com/content/www/us/en/ethernet-controllers/82599-10-g > > be-con > > troller-datasheet.html > > > > Other cards require NDA or other agreements to get details of RSS. > > > > If you have a performance problem, may I suggest you use kernel 3.10 then > monitor system activity with "perf" command. For instance you can = start > with "perf top -a" this will give you nice information. Then your > creativity will do the rest ;-) You may be surprised what comes on the = top > hot points... > > (the most unexpected hot function I found here was Linux syscall > > gettimeofday!!!) > > > > Fran=E7ois-Fr=E9d=E9ric > > > >> -----Message d'origine----- > >> De : dev [mailto:dev-bounces@dpdk.org] De la part de Michael > >> Quicquaro Envoy=E9 : mercredi 4 d=E9cembre 2013 18:53 =C0 : = dev@dpdk.org Objet > : > >> [dpdk-dev] generic load balancing > >> > >> Hi all, > >> I am writing a dpdk application that will receive packets from one > >> interface and process them. It does not forward packets in the > > traditional > >> sense. However, I do need to process them at full line rate and > >> therefore need more than one core. The packets can be somewhat > >> generic in nature > > and > >> can be nearly identical (especially at the beginning of the = packet). > >> I've used the rxonly function of testpmd as a model. > >> > >> I've run into problems in processing a full line rate of data since > >> the nature of the data causes all the data to be presented to only = one > core. > > I > >> get a large percentage of dropped packets (shows up as Rx-Errors in > >> "port > >> stats") because of this. I've tried modifying the data so that > >> packets have different UDP ports and that seems to work when I use > >> --rss-udp > >> > >> My questions are: > >> 1) Is there a way to configure RSS so that it alternates packets to > >> all configured cores regardless of the packet data? > >> > >> 2) Where is the best place to learn more about RSS and how to > >> configure it? I have not found much in the DPDK documentation. > >> > >> Thanks for the help, > >> - Mike > > > > > > > > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > =3D=3D=3D=3D=3D=3D=3D=3D=3D Please refer to > > http://www.aricent.com/legal/email_disclaimer.html > > for important disclosures regarding this electronic communication. > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > =3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > =3D=3D=3D=3D > Please refer to http://www.aricent.com/legal/email_disclaimer.html > for important disclosures regarding this electronic communication. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > =3D=3D=3D=3D