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 A351AA0526; Wed, 8 Jul 2020 13:57:10 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 523CA1DB87; Wed, 8 Jul 2020 13:57:09 +0200 (CEST) Received: from new4-smtp.messagingengine.com (new4-smtp.messagingengine.com [66.111.4.230]) by dpdk.org (Postfix) with ESMTP id 0102D1DB76 for ; Wed, 8 Jul 2020 13:57:06 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id 56EFE5803D4; Wed, 8 Jul 2020 07:57:06 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 08 Jul 2020 07:57:06 -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= Yb0ir9bzLF2rs3wDdzNjr6UgtMeEi8+3LmBspgYI5hA=; b=m4qRZ/CpwqMgGZpA n90gWyTTWQZYPUtJDZ/nYT0PuBMlf+SGsmzzyaZRTz9QhFhkBEuNnoRJW45/9E/d qXgkag4KUmU3q7U4gbVgHTSqSV99FVWj34M18mA3TZ7YZ/gHJBymTfsKV2ngCiWx n1uXMqiMUARAnp9emH8ho7KjkqyhpVw+P6gKzLeYhWnsF8VfZvfWOMEqKibCPcMl aBvG9ruNDtBPaywQlMIhua3Jqp5SJp5vgqm4PlgKZEjVTU9yZkq1nCNaP5tgmrak LbT/FA53CgGIO02ylN+/f8R0bR31UVgd8LVvnAgnOsB142AGuiIxQ+SsLhKf4My5 zm4AYw== 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=Yb0ir9bzLF2rs3wDdzNjr6UgtMeEi8+3LmBspgYI5 hA=; b=d09mCtb+31m2A1miMDVhAT2H7XnUI9fYnFNdwcMG1E/KmB9C+sIYP4s2a icXxRFyQ6a247VLpTk9+/ntPNQxkZ8qaMKFbkcYPdNeXLGa1NsGil1gToEJlvbPZ lHRylTHxD+NaqyVXyPH05BaUCSLzoJmNN7Zb9L4bpVJ3Bs1BNSjY+Q5WtpXQJsOO AgzQwTJGDTKsVCDxSrw5WXAGsQh1wOV28zRZAa9LOUTi7F4hcMWJPmsJHuTYgNut GSo8QJ+xsTc40OTROs0K7MCPxM7cVNwcvgxMEgjqmxDTpHe71V2WTOCJchm1EQcs UM99LmbU01PP73R0SAGvdu9i1PDbw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudejgdegiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpeefleehieetteetgfdukeetiefhieetgfdvfefhtddvieefgffgheet feefudeufeenucffohhmrghinhepihgvthhfrdhorhhgnecukfhppeejjedrudefgedrvd dtfedrudekgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhr ohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght 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 6D4D3328006A; Wed, 8 Jul 2020 07:57:04 -0400 (EDT) From: Thomas Monjalon 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" Date: Wed, 08 Jul 2020 13:57:03 +0200 Message-ID: <5246418.gzuaxCN7mb@thomas> In-Reply-To: <039ED4275CED7440929022BC67E7061154858443@SHSMSX103.ccr.corp.intel.com> References: <20200612080711.39774-1-junfeng.guo@intel.com> <2168344.3qRs3v1SFd@thomas> <039ED4275CED7440929022BC67E7061154858443@SHSMSX103.ccr.corp.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 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. > > > > 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 > > OK, we are going change all the ETH_RSS_xxx to RTE_ETH_RSS_xxx, or just the new values? > the first option looks make sense to me. You cannot break compatibility with the existing values, but you can provide an alias to preserve compatibility. > > > 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. > > 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. > 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 solutions.