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 A3AF5A04AC; Tue, 1 Sep 2020 15:23:38 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 846901C0DC; Tue, 1 Sep 2020 15:23:21 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 58A601C0CD for ; Tue, 1 Sep 2020 15:23:20 +0200 (CEST) IronPort-SDR: KuPaUaVBhq/C+IjE2GtKUpQJ1pHKb1E2iNZULH+kJe/YR221R1RecGaQE6TOlFHzsZExbUMzjO nUNSg532eNqg== X-IronPort-AV: E=McAfee;i="6000,8403,9730"; a="156419501" X-IronPort-AV: E=Sophos;i="5.76,379,1592895600"; d="scan'208";a="156419501" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Sep 2020 06:23:19 -0700 IronPort-SDR: YH/TMNqIiT4pBG6gkYhqgr0djXn612TQpQFeuKdffJz1mMvahNQhZL51kOaNf3RpaVcEjg/Z2X MaqAIU2rCfTA== X-IronPort-AV: E=Sophos;i="5.76,379,1592895600"; d="scan'208";a="502237728" Received: from fyigit-mobl.ger.corp.intel.com (HELO [10.213.211.143]) ([10.213.211.143]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Sep 2020 06:23:12 -0700 To: Andrew Rybchenko , kirankumark@marvell.com, Thomas Monjalon Cc: dev@dpdk.org, jerinj@marvell.com, orika@mellanox.com, xuanziyang2@huawei.com, cloud.wangxiaoyun@huawei.com, zhouguoyang@huawei.com, rosen.xu@intel.com, beilei.xing@intel.com, jia.guo@intel.com, rmody@marvell.com, shshaikh@marvell.com, ndabilpuram@marvell.com, qiming.yang@intel.com, qi.z.zhang@intel.com, keith.wiles@intel.com, hemant.agrawal@nxp.com, sachin.saxena@nxp.com, wei.zhao1@intel.com, johndale@cisco.com, hyonkim@cisco.com, chas3@att.com, matan@mellanox.com, shahafs@mellanox.com, viacheslavo@mellanox.com, rahul.lakkireddy@chelsio.com, grive@u256.net, lironh@marvell.com, jingjing.wu@intel.com, xavier.huwei@huawei.com, humin29@huawei.com, yisen.zhuang@huawei.com, ajit.khaparde@broadcom.com, somnath.kotur@broadcom.com, jasvinder.singh@intel.com, cristian.dumitrescu@intel.com References: <20200819060446.2264111-1-kirankumark@marvell.com> <20200821110330.214931-1-kirankumark@marvell.com> <28785b8b-8b38-6387-56f1-45fa19da892c@solarflare.com> From: Ferruh Yigit Message-ID: Date: Tue, 1 Sep 2020 14:23:08 +0100 MIME-Version: 1.0 In-Reply-To: <28785b8b-8b38-6387-56f1-45fa19da892c@solarflare.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v6 1/3] ethdev: add level support for RSS offload types 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" On 8/29/2020 3:52 PM, Andrew Rybchenko wrote: > On 8/21/20 2:03 PM, kirankumark@marvell.com wrote: >> From: Kiran Kumar K >> >> This patch reserves 2 bits as input selection to select Inner and >> outer layers for RSS computation. It is combined with existing >> ETH_RSS_* to choose Inner or outer layers for L2, L3 and L4. >> This functionality already exists in rte_flow through level parameter in >> RSS action configuration rte_flow_action_rss. >> >> Signed-off-by: Kiran Kumar K >> --- >> V7 Changes: >> * Split ethdev and testpmd changes into seperate patches. >> >> lib/librte_ethdev/rte_ethdev.h | 27 +++++++++++++++++++++++++++ >> 1 file changed, 27 insertions(+) >> >> diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h >> index 70295d7ab..2a3a76d37 100644 >> --- a/lib/librte_ethdev/rte_ethdev.h >> +++ b/lib/librte_ethdev/rte_ethdev.h >> @@ -552,6 +552,33 @@ struct rte_eth_rss_conf { >> #define RTE_ETH_RSS_L3_PRE64 (1ULL << 53) >> #define RTE_ETH_RSS_L3_PRE96 (1ULL << 52) >> >> +/* >> + * We use the following macros to combine with the above layers to choose >> + * inner and outer layers or both for RSS computation. >> + * Note: Default is 0: inner layers, 1: outer layers, 2: both >> + * bit 50 and 51 are reserved for this. >> + */ >> + >> +/** >> + * Level 0, It basically stands for the innermost encapsulation level RSS >> + * can be performed on according to PMD and device capabilities. >> + */ >> +#define ETH_RSS_LEVEL_INNER (0ULL << 50) > > You're trying to refer to struct rte_flow_action_rss level definition > when values are chosen, but I think it is > inaccurate. Primary definition of the level==0 is PMD default, > not inner. Definition says that typically it is the innermost > encapsulation level RSS can be performed on according to PMD > and device capabilities. But it is secondary, primary > definition is "PMD default". Basically unspecified by the > caller (structure memset to 0) results in default behaviour. > >> +/** >> + * Level 1, It basically stands for the outermost encapsulation level RSS >> + * can be performed on according to PMD and device capabilities. >> + */ >> +#define ETH_RSS_LEVEL_OUTER (1ULL << 50) >> +/** >> + * Level 2, It basically stands for the both inner and outermost >> + * encapsulation level RSS can be performed on according to PMD and >> + * device capabilities. >> + */ >> +#define ETH_RSS_LEVEL_INNER_OUTER (2ULL << 50) > > Level equal to 2 is the first after the outermost inner level. > Level equal to 3 is the second after the outermost inner level > and so on. > > If we really try to follow level definition from > rte_flow_action_rss, the problem is that these defines > are used to define RSS hashing capabilities in > dev_info.flow_type_rss_offloads. Support for level > up to 3 levels, does not mean that we can hash on any, > it could be either outermost or innermost level, but > not the middle level, if 3 levels are present. > Or just innermost recognized: either the first one > if no tunnels recognized, the second if two levels > are recognized, or the third one if three levels are > recognized. Is the more than two levels practically have a usage? I can see rte_flow accepts any number as level but if it is not practically a concern I think we can go with 'inner' & 'outer' only. And defer more level concern for now. Even with only 'inner' & 'outer', capability reporting can be a problem tough. Like if a PMD can calculate hash for inner and outer for TCP but only for outer for UDP, how can PMD report this capability? Again not sure if this is a practically valid concern. > > Sorry, that I'm not proposing any solution right now. > Just need more time to thing about it. > You're welcome to try to cover these requirements. > >> +#define ETH_RSS_LEVEL_MASK (3ULL << 50) >> + >> +#define ETH_RSS_LEVEL(rss_hf) ((rss_hf & ETH_RSS_LEVEL_MASK) >> 50) >> + >> /** >> * For input set change of hash filter, if SRC_ONLY and DST_ONLY of >> * the same level are used simultaneously, it is the same case as >> -- >> 2.25.1 >> >