From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 94A755580 for ; Fri, 22 Jul 2016 18:33:04 +0200 (CEST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga104.fm.intel.com with ESMTP; 22 Jul 2016 09:33:04 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,405,1464678000"; d="scan'208";a="1012050333" Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by fmsmga001.fm.intel.com with ESMTP; 22 Jul 2016 09:33:01 -0700 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.123]) by IRSMSX101.ger.corp.intel.com ([169.254.1.155]) with mapi id 14.03.0248.002; Fri, 22 Jul 2016 17:33:00 +0100 From: "Chandran, Sugesh" To: Adrien Mazarguil CC: "dev@dpdk.org" , Thomas Monjalon , "Zhang, Helin" , "Wu, Jingjing" , Rasesh Mody , Ajit Khaparde , Rahul Lakkireddy , "Lu, Wenzhuo" , "Jan Medala" , John Daley , "Chen, Jing D" , "Ananyev, Konstantin" , Matej Vido , "Alejandro Lucero" , Sony Chacko , Jerin Jacob , "De Lara Guarch, Pablo" , Olga Shern , "Chilikin, Andrey" Thread-Topic: [dpdk-dev] [RFC] Generic flow director/filtering/classification API Thread-Index: AQHR1ul13SVB/Bo7y0+HNDeMrG3/bKANL2ZggAFEKwCABIVXkIADy76AgAFiwZCAAW5AAIAEmm7ggAAbk4CAA0s2kP///cuAgAE7YbCAABtUgIAB0L4g Date: Fri, 22 Jul 2016 16:32:59 +0000 Message-ID: <2EF2F5C0CC56984AA024D0B180335FCB13E0903C@IRSMSX102.ger.corp.intel.com> References: <20160708130310.GD7621@6wind.com> <2EF2F5C0CC56984AA024D0B180335FCB13DEB236@IRSMSX102.ger.corp.intel.com> <20160713200327.GC7621@6wind.com> <2EF2F5C0CC56984AA024D0B180335FCB13DEE55F@IRSMSX102.ger.corp.intel.com> <20160715150402.GE7621@6wind.com> <2EF2F5C0CC56984AA024D0B180335FCB13E02938@IRSMSX102.ger.corp.intel.com> <20160718150029.GJ7621@6wind.com> <2EF2F5C0CC56984AA024D0B180335FCB13E05C5C@IRSMSX102.ger.corp.intel.com> <20160720171033.GQ7621@6wind.com> <2EF2F5C0CC56984AA024D0B180335FCB13E062E8@IRSMSX102.ger.corp.intel.com> <20160721133709.GS7621@6wind.com> In-Reply-To: <20160721133709.GS7621@6wind.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [RFC] Generic flow director/filtering/classification API 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: Fri, 22 Jul 2016 16:33:05 -0000 HI Adrien, Thank you for your effort and considering the inputs and comments. The design looks fine for me now. Regards _Sugesh > -----Original Message----- > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com] > Sent: Thursday, July 21, 2016 2:37 PM > To: Chandran, Sugesh > Cc: dev@dpdk.org; Thomas Monjalon ; > Zhang, Helin ; Wu, Jingjing > ; Rasesh Mody ; Ajit > Khaparde ; Rahul Lakkireddy > ; Lu, Wenzhuo ; > Jan Medala ; John Daley ; Chen, > Jing D ; Ananyev, Konstantin > ; Matej Vido ; > Alejandro Lucero ; Sony Chacko > ; Jerin Jacob > ; De Lara Guarch, Pablo > ; Olga Shern ; > Chilikin, Andrey > Subject: Re: [dpdk-dev] [RFC] Generic flow director/filtering/classificat= ion > API >=20 > Hi Sugesh, >=20 > I do not have much to add, please see below. >=20 > On Thu, Jul 21, 2016 at 11:06:52AM +0000, Chandran, Sugesh wrote: > [...] > > > > RSS hashing support :- Just to confirm, the RSS flow action allows > > > > application to decide the header fields to produce the hash. This > > > > gives programmability on load sharing across different queues. The > > > > application can program the NIC to calculate the RSS hash only > > > > using mac or mac+ ip or ip only using this. > > > > > > I'd say yes but from your summary, I'm not sure we share the same > > > idea of what the RSS action is supposed to do, so here is mine. > > > > > > Like all flow rules, the pattern part of the RSS action only filters > > > the packets on which the action will be performed. > > > > > > The rss_conf parameter (struct rte_eth_rss_conf) only provides a key > > > and a RSS hash function to use (ETH_RSS_IPV4, > > > ETH_RSS_NONFRAG_IPV6_UDP, etc). > > > > > > Nothing prevents the RSS hash function from being applied to > > > protocol headers which are not necessarily present in the flow rule > > > pattern. These are two independent things, e.g. you could have a > > > pattern matching IPv4 packets yet perform RSS hashing only on UDP > headers. > > > > > > Finally, the RSS action configuration only affects packets coming > > > from this flow rule. It is not performed on the device globally so > > > packets which are not matched are not affected by RSS processing. As > > > a result it might not be possible to configure two flow rules > > > specifying incompatible RSS actions simultaneously if the underlying > > > device supports only a single global RSS context. > > > > > [Sugesh] thank you for the explanation. This means I can have a rule > > that matches on Every incoming packets(all field wild card rule) and > > does RSS hash on selected fields, MAC only, IP only or IP & MAC? >=20 > Yes, I guess it could even replace the current method for configuring RSS= on a > device in a more versatile fashion, but this is a topic for another debat= e. >=20 > Let's implement this API first! >=20 > > This can be useful to do a packet lookup in software by just using > > Only hash. >=20 > Not sure to fully understand your idea, but I'm positive it could be done > somehow :) >=20 > -- > Adrien Mazarguil > 6WIND