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 0A827A00BE; Wed, 8 Jul 2020 11:57:36 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 95FF01DC0A; Wed, 8 Jul 2020 11:57:35 +0200 (CEST) Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) by dpdk.org (Postfix) with ESMTP id A2A261DBB8 for ; Wed, 8 Jul 2020 11:57:34 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id 4EA605803A8; Wed, 8 Jul 2020 05:57:34 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 08 Jul 2020 05:57:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm1; bh= J60lNKG/XyVkDDc/KUMGVET2xls56RjsgWiZtrTWZSc=; b=tveb2MRVXkpPrExT wKfjj8mFMVvrjE/Lvh7ErOTDYChRhrySrJD1PnWoIXlwAjIvoZTCR0tsxJIkT/e4 U0157jsujySek8JlO9w7GALqG8Sz4KFx7h6ua76QUgzTH6t6BjEXZ8JGdg+30Es/ LxBglZv1sq21HMi4cLk0FJjjnibcc7HJiZ8yelDpe6b7+tEIYDBaOyW6k2KvvaG6 41i0xB0AEhBfYxluGAIy3uXPs7OeRjZxLqE3YT+kjFKu11Z8z7WR4zwf4p4Dtkka bJAPa8U8Zz1BOrrCwBBmElaId6s7aDaEyDPrXm3w2m2G34se26pHREnwiiTanawf YzkFRA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=J60lNKG/XyVkDDc/KUMGVET2xls56RjsgWiZtrTWZ Sc=; b=Ns6jornvNlei+l97eDxawlVyDnY3ouUaA33C2U2SjLuLp4snh71bOJ5yZ YmXFElNDD28b6vqVU/nRAko7iOykhQqccLenBHsKsf2EiAkXVXsBiB9bACE9JIIm lG7JvoIChUACbiS2KST5mfpg1DiZAlvEhSEMPFMBwL5mC+5g8E5nxibyNXnKrxSy nfZDjKe/Dtop7X7L8H5njkrrqcH1M6+afJXf7sHG5sb5UecBP5AwkoMGujvMy8LM ItFzxW496nA5KYawSJVxb6A/RR7Ys3/Ep63p7c/TF8khYFrf9MUaeQ+mPq7YGzHi jkjGbFwRGNmZ/8VCnaHq9b295IooQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudejgddvvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhephffvufffkfgjfhgggfgtsehtufertd dttddvnecuhfhrohhmpefvhhhomhgrshcuofhonhhjrghlohhnuceothhhohhmrghssehm ohhnjhgrlhhonhdrnhgvtheqnecuggftrfgrthhtvghrnhepudeggfdvfeduffdtfeegle fghfeukefgfffhueejtdetuedtjeeuieeivdffgeehnecukfhppeejjedrudefgedrvddt fedrudekgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 675AE3280060; Wed, 8 Jul 2020 05:57:32 -0400 (EDT) From: Thomas Monjalon To: xiaolong.ye@intel.com, beilei.xing@intel.com, "Zhang, Qi Z" Cc: dev@dpdk.org, jia.guo@intel.com, junfeng.guo@intel.com, simei.su@intel.com, ferruh.yigit@intel.com, arybchenko@solarflare.com, viacheslavo@mellanox.com, jerinj@marvell.com, ajit.khaparde@broadcom.com, orika@mellanox.com Date: Wed, 08 Jul 2020 11:57:31 +0200 Message-ID: <2168344.3qRs3v1SFd@thomas> In-Reply-To: <5a8a00e4-0e13-b60f-53e8-644f83ebf0de@intel.com> References: <20200612080711.39774-1-junfeng.guo@intel.com> <3862163.zQz20bWevW@thomas> <5a8a00e4-0e13-b60f-53e8-644f83ebf0de@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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" 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. > > Do we want to continue with the RTE_ prefix missing? > > Can't we add the prefix for the new values? I think you misunderstood this question. I am asking to change the name ETH_RSS_L3_PRE32 to RTE_ETH_RSS_L3_PRE32 > 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 couple 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. 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. > 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 solutions.