From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 31B8FA00E6 for ; Tue, 9 Jul 2019 07:41:33 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B99A7324D; Tue, 9 Jul 2019 07:41:32 +0200 (CEST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 02FD83237 for ; Tue, 9 Jul 2019 07:41:30 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jul 2019 22:41:30 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.63,469,1557212400"; d="scan'208";a="192569977" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by fmsmga002.fm.intel.com with ESMTP; 08 Jul 2019 22:41:29 -0700 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 8 Jul 2019 22:41:29 -0700 Received: from shsmsx105.ccr.corp.intel.com ([169.254.11.232]) by shsmsx102.ccr.corp.intel.com ([169.254.2.3]) with mapi id 14.03.0439.000; Tue, 9 Jul 2019 13:41:27 +0800 From: "Zhang, Qi Z" To: Adrien Mazarguil CC: "Su, Simei" , "Wu, Jingjing" , "Xing, Beilei" , "Yang, Qiming" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [RFC] ethdev: support input set change by RSS action Thread-Index: AQHVMil+v9G0tQ8LMU+d8fZoI/lftKa5pVSAgADTNED//4ERAIAH0Hfw Date: Tue, 9 Jul 2019 05:41:26 +0000 Message-ID: <039ED4275CED7440929022BC67E7061153D61FCA@SHSMSX105.ccr.corp.intel.com> References: <1562215629-75520-1-git-send-email-simei.su@intel.com> <20190704090719.GK4512@6wind.com> <039ED4275CED7440929022BC67E7061153D5FFD8@SHSMSX105.ccr.corp.intel.com> <20190704140856.GO4512@6wind.com> In-Reply-To: <20190704140856.GO4512@6wind.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOTBjMDg5YTYtYTg3Ny00ODVkLWI3YWUtNTM2NTQwNTM4MzlhIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiQWpNOFlNMDFzMlZKQ25iODZWWHpjVVNhZUg2dlpPQ0VcLzhJaDhlTmxMQUY2OUFmS1wvcW5FanZmSjFYTXI4N2ZRIn0= x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.600.7 dlp-reaction: no-action x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [RFC] ethdev: support input set change by RSS action X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Adrien: > -----Original Message----- > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com] > Sent: Thursday, July 4, 2019 10:09 PM > To: Zhang, Qi Z > Cc: Su, Simei ; Wu, Jingjing ; > Xing, Beilei ; Yang, Qiming ; > dev@dpdk.org > Subject: Re: [dpdk-dev] [RFC] ethdev: support input set change by RSS act= ion >=20 > On Thu, Jul 04, 2019 at 01:55:14PM +0000, Zhang, Qi Z wrote: > > > > > > > -----Original Message----- > > > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com] > > > Sent: Thursday, July 4, 2019 5:07 PM > > > To: Su, Simei > > > Cc: Zhang, Qi Z ; Wu, Jingjing > > > ; Xing, Beilei ; Yang, > > > Qiming ; dev@dpdk.org > > > Subject: Re: [dpdk-dev] [RFC] ethdev: support input set change by > > > RSS action > > > > > > On Thu, Jul 04, 2019 at 12:47:09PM +0800, simei wrote: > > > > From: Simei Su > > > > > > > > This RFC introduces inputset structure to rte_flow_action_rss to > > > > support input set specific configuration by rte_flow RSS action. > > > > > > > > We can give an testpmd command line example to make it more clear. > > > > > > > > For example, below flow selects the l4 port as inputset for any > > > > eth/ipv4/tcp packet: #flow create 0 ingress pattern eth / ipv4 / > > > > tcp / end actions rss inputset tcp src mask 0xffff dst mask 0xffff > > > > /end > > > > > > > > Signed-off-by: Simei Su > > > > --- > > > > lib/librte_ethdev/rte_flow.h | 3 +++ > > > > 1 file changed, 3 insertions(+) > > > > > > > > diff --git a/lib/librte_ethdev/rte_flow.h > > > > b/lib/librte_ethdev/rte_flow.h index f3a8fb1..2a455b6 100644 > > > > --- a/lib/librte_ethdev/rte_flow.h > > > > +++ b/lib/librte_ethdev/rte_flow.h > > > > @@ -1796,6 +1796,9 @@ struct rte_flow_action_rss { > > > > uint32_t queue_num; /**< Number of entries in @p queue. */ > > > > const uint8_t *key; /**< Hash key. */ > > > > const uint16_t *queue; /**< Queue indices to use. */ > > > > + struct rte_flow_item *inputset; /** Provide more specific > > > > +inputset > > > configuration. > > > > + * ignore spec, only mask. > > > > + */ > > > > }; > > > > > > > > /** > > > > > > To make sure I understand, is this kind of a more flexible version > > > of rte_flow_action_rss.types? > > > > Yes > > > > > > For instance while specifying .types =3D ETH_RSS_IPV4 normally covers > > > both source and destination addresses, does this approach enable > > > users to perform RSS on source IP only? > > > > Yes, .it is the case to select any subset of 5 tuples or even tunnel > > header's id for hash > > > > > In which case, what value does the Toeplitz algorithm assume for the > > > destination, 0x0? (note: must be documented) > > > > My understanding is src/dst pair is only required for a symmetric case > > But for Toeplitz, it is just a hash function, it process a serial of > > data with specific algorithm, have no idea about which part is src and = dst , So > for ip src only with Toeplitz, dst is not required to be a placeholder.. >=20 > Right, I had symmetric Toeplitz in mind and wondered what would happen > when users would not select the required fields. I guess the PMD would ha= ve > to reject unsupported combinations. >=20 > > anything I missed, would you share more insight? >=20 > No, that answers the question, thanks. >=20 > Now what about my suggestion below? In short: extending ETH_RSS_* > assuming there's enough bits left in there, instead of adding a whole new > framework and breaking ABI in the process. Since the hardware can support any combination of input set (not just 5 tup= les), we'd like to make it more generic. Those will be some pain due to ABI break, but we think its worth for long t= erm. Thanks Qi >=20 > > > My opinion is that, unless you know of a hardware which can perform > > > RSS on random bytes of a packet, this approach is a bit overkill at t= his > point. > > > > > > How about simply adding the needed ETH_RSS_* definitions (e.g. > > > ETH_RSS_IPV4_(SRC|DST))? How many are needed? > > > > > > There are currently 20 used bits and struct > > > rte_flow_action_rss.types is 64-bit wide. I'm sure we can manage > > > something without harming the ABI. Even better, you wouldn't need a > deprecation notice. > > > > > > If you use the suggested approach, please update testpmd and its > > > documentation as part of the same patch, thanks. >=20 > -- > Adrien Mazarguil > 6WIND