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 4F48FA0526; Wed, 8 Jul 2020 14:37:51 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2549A1DD48; Wed, 8 Jul 2020 14:37:51 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 0B2B61DC6A for ; Wed, 8 Jul 2020 14:37:48 +0200 (CEST) IronPort-SDR: /UwZIrjGphBfpZX3ZmoZEU1B55+z/TSrsRA9xjvrgVMSfA4h5MjUGpUdy99s8hooliEa+L9bkB 4J4iKFOug8Ew== X-IronPort-AV: E=McAfee;i="6000,8403,9675"; a="149294527" X-IronPort-AV: E=Sophos;i="5.75,327,1589266800"; d="scan'208";a="149294527" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jul 2020 05:37:29 -0700 IronPort-SDR: QiJEbPzSX/zfxts6qVGcIc6YyZdkS9QDYWuIy3xVSm7n4eQ5cnTF+BZHT1R+nf/xVqTJhWDcN8 fQqB8pY6vFow== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,327,1589266800"; d="scan'208";a="297704705" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by orsmga002.jf.intel.com with ESMTP; 08 Jul 2020 05:37:29 -0700 Received: from fmsmsx115.amr.corp.intel.com (10.18.116.19) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 8 Jul 2020 05:37:29 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by fmsmsx115.amr.corp.intel.com (10.18.116.19) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 8 Jul 2020 05:37:28 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.22]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.49]) with mapi id 14.03.0439.000; Wed, 8 Jul 2020 20:37:25 +0800 From: "Zhang, Qi Z" To: Thomas Monjalon , "Xing, Beilei" CC: "dev@dpdk.org" , "Guo, Jia" , "Guo, Junfeng" , "Su, Simei" , "Yigit, Ferruh" , "arybchenko@solarflare.com" , "viacheslavo@mellanox.com" , "jerinj@marvell.com" , "ajit.khaparde@broadcom.com" , "orika@mellanox.com" Thread-Topic: [dpdk-dev] [PATCH v2 1/3] ethdev: add new RSS types for IPv6 prefix Thread-Index: AQHWQ7a011zWOy0smEWiQz0KNMS5A6j7j+KAgAIBrwD//31JgIAAiJug//+YyoCAAIdUMP//gNWAABD/psA= Date: Wed, 8 Jul 2020 12:37:25 +0000 Message-ID: <039ED4275CED7440929022BC67E7061154858537@SHSMSX103.ccr.corp.intel.com> References: <20200612080711.39774-1-junfeng.guo@intel.com> <5246418.gzuaxCN7mb@thomas> <039ED4275CED7440929022BC67E70611548584E5@SHSMSX103.ccr.corp.intel.com> <1845327.VSnYL2Xkle@thomas> In-Reply-To: <1845327.VSnYL2Xkle@thomas> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.2.0.6 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] [PATCH v2 1/3] ethdev: add new RSS types for IPv6 prefix 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" > -----Original Message----- > From: Thomas Monjalon > Sent: Wednesday, July 8, 2020 8:26 PM > To: Xing, Beilei ; Zhang, Qi Z > Cc: dev@dpdk.org; Guo, Jia ; Guo, Junfeng > ; Su, Simei ; Yigit, Ferruh > ; arybchenko@solarflare.com; > viacheslavo@mellanox.com; jerinj@marvell.com; > ajit.khaparde@broadcom.com; orika@mellanox.com > Subject: Re: [dpdk-dev] [PATCH v2 1/3] ethdev: add new RSS types for IPv6 > prefix >=20 > 08/07/2020 14:05, Zhang, Qi Z: > > From: Thomas Monjalon > > > 08/07/2020 13:10, Zhang, Qi Z: > > > > From: Thomas Monjalon > > > > > 08/07/2020 11:45, Zhang, Qi Z: > > > > > > On 2020/7/7 19:06, Thomas Monjalon wrote: > > > > > > > 16/06/2020 10:16, Junfeng Guo: > > > > > > >> This patch defines new RSS offload types for IPv6 prefix > > > > > > >> with 32, 48, > > > > > > >> 64 bits of both SRC and DST IPv6 address. > > > > > > >> > > > > > > >> Signed-off-by: Junfeng Guo > > > > > > >> --- > > > > > > >> lib/librte_ethdev/rte_ethdev.h | 51 > > > > > ++++++++++++++++++++++++++++++++++ > > > > > > >> 1 file changed, 51 insertions(+) > > > > > > >> > > > > > > >> diff --git a/lib/librte_ethdev/rte_ethdev.h > > > > > > >> b/lib/librte_ethdev/rte_ethdev.h index 631b146bd..5a7ba36d8 > > > > > > >> 100644 > > > > > > >> --- a/lib/librte_ethdev/rte_ethdev.h > > > > > > >> +++ b/lib/librte_ethdev/rte_ethdev.h > > > > > > >> @@ -538,6 +538,9 @@ struct rte_eth_rss_conf { > > > > > > >> #define ETH_RSS_L4_DST_ONLY (1ULL << 60) > > > > > > >> #define ETH_RSS_L2_SRC_ONLY (1ULL << 59) > > > > > > >> #define ETH_RSS_L2_DST_ONLY (1ULL << 58) > > > > > > >> +#define ETH_RSS_L3_PRE32 (1ULL << 57) > > > > > > >> +#define ETH_RSS_L3_PRE48 (1ULL << 56) > > > > > > >> +#define ETH_RSS_L3_PRE64 (1ULL << 55) > > > > > > > > > > > > > > PRE32, 48 and 64 are not obvious. > > > > > > > Why is it needed? > > > > > > > > > > > > there is typical usage for NAT64, which use 32 bit prefix for > > > > > > IPv6 addresses, in this case flows over IPv4 and IPv6 will > > > > > > result in the same hash value, as well as 48, 64, which also > > > > > > have some corresponding use cases, > > > > > > > At least, please add comments for the values of this API. > > > > > > > > > > > > sure, we will add more comments. > [...] > > > > > > 32, 48, 64 are typical usage, and consider suffix pair we may > > > > > > add later, it will cost 6 bits so far we still have 27 bit > > > > > > left, so it looks like will not be a problem in following coup= le > releases. > > > > > > > > > > Having some space left is not a reason to waste it :) If I > > > > > understand well, there is no standard for this API. > > > > > You are assigning some bits to some usage. > > > > > I don't find it generic and flexible enough. > > > > > > > > Actually IPv6 address prefix is in spec, please check below RFC. > > > > https://tools.ietf.org/html/rfc6052#page-5 > > > > > > Quoting the RFC: > > > " > > > the prefix shall be either the "Well-Known Prefix" > > > or a "Network-Specific Prefix" unique to the organization > > > deploying the address translators. > > > The prefixes can only have one of the following lengths: > > > 32, 40, 48, 56, 64, or 96. > > > (The Well-Known Prefix is 96 bits long, and can only be used > > > in the last form of the table.) > > > " > > > > > > So 40 and 56 are missing. > > > > Yes, like to add and lets accelerate the progress to abandon the old > > APIs :) >=20 > Please could list which part of the existing API you would like to deprec= ate in > future? I think it's a new version of rte_flow_action_rss, we need a more generic w= ay to describe the RSS input set of a flow But not just a 64 bits type, then all ETH_RSS_xxx will be decoupled from rt= e_flow. >=20 >=20 > > > > So probably we are not wasting bits here, since this is a typical > > > > usage that DPDK can provide. > > > > Of cause more description is needed in the code here. > > > > > > > > > If you want to limit the size of the match, we should have a > > > > > generic syntax to choose how many bits of the IPv6 address are > > > > > taken into account for RSS. Or maybe an IPv6 mask. > > > > > > > > Yes, I believe at some moment, a more generic solution is > > > > mandatory, And I think that will not work if we stick on the 64 > > > > bits, new API need to be introduced and old one should be > > > > abandoned > > > > > > > > > > > > > > > but anyway use 64 bits to represent RSS inputset can't meet > > > > > > the coming complex RSS usage, we may need to figure out some > > > > > > new APIs and > > > > > abandon > > > > > > the old one. > > > > > > A stacked protocol layer with bit field selector in each layer > > > > > > is under consideration, hope we can contribute some RFC at > > > > > > some > > > moment. > > > > > > also feel free let us know your thought. > > > > > > > > > > My thought is to discuss how to fit this need in future and > > > > > avoid adding few bits of temporary workaround. > > > > > API definition is serious and we must avoid temporary half soluti= ons. >=20 >=20