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 7B39FA00BE; Wed, 8 Jul 2020 11:45:30 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2FDA61DA9A; Wed, 8 Jul 2020 11:45:29 +0200 (CEST) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id A29651D502 for ; Wed, 8 Jul 2020 11:45:27 +0200 (CEST) IronPort-SDR: j8LEqQdCBCJv37NPKkvEJag4V37+WQRNQVtkrwjE58xZAYs4ZLY5BXlvgmTOZ3r4iQG/k5AoGn t/CRpxiqGfyA== X-IronPort-AV: E=McAfee;i="6000,8403,9675"; a="209298297" X-IronPort-AV: E=Sophos;i="5.75,327,1589266800"; d="scan'208";a="209298297" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jul 2020 02:45:26 -0700 IronPort-SDR: rVH23jw6WvFbOPkrBRr+NFAHaP07JZHSulLHSq394OnIzjZkXx/umIB2xcP7KvP1IcqzJVvZyI p4QlOVF9uQ+A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,327,1589266800"; d="scan'208";a="283744306" Received: from qzhan15-mobl.ccr.corp.intel.com (HELO [10.255.31.190]) ([10.255.31.190]) by orsmga006.jf.intel.com with ESMTP; 08 Jul 2020 02:45:23 -0700 To: Thomas Monjalon , xiaolong.ye@intel.com, beilei.xing@intel.com 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 References: <20200612080711.39774-1-junfeng.guo@intel.com> <20200616081644.23887-1-junfeng.guo@intel.com> <20200616081644.23887-2-junfeng.guo@intel.com> <3862163.zQz20bWevW@thomas> From: "Zhang, Qi Z" Message-ID: <5a8a00e4-0e13-b60f-53e8-644f83ebf0de@intel.com> Date: Wed, 8 Jul 2020 17:45:22 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <3862163.zQz20bWevW@thomas> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US 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" Hi Thomas: Sorry for late reply, see comment inline. 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? 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. 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. > > Note: ethdev maintainers were not Cc'ed. > This reason is enough to nack the patch. sure, will send a new version to follow this Thanks Qi > > >