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 6D7A5A04AC; Tue, 1 Sep 2020 15:37:55 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id AAA161C0AF; Tue, 1 Sep 2020 15:37:54 +0200 (CEST) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id C75B11C0AC for ; Tue, 1 Sep 2020 15:37:52 +0200 (CEST) IronPort-SDR: ImoQ+x+Q5VrPxNTcgdtMa/EmJKpeI7fI1ekqvLGZl0TnO3H+gWosAMoV1O5KWOQM+qMp+4kqLY +Vn9HjFNobiw== X-IronPort-AV: E=McAfee;i="6000,8403,9730"; a="137209782" X-IronPort-AV: E=Sophos;i="5.76,379,1592895600"; d="scan'208";a="137209782" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Sep 2020 06:37:48 -0700 IronPort-SDR: S4J8BpIWd0DEc5zqHYAru4/U2+S7QTsguo24ClGt1EllEbAdKOY7CWlUd7ksaVDPXQdzmRCVre 0IyAXnrBf0aw== X-IronPort-AV: E=Sophos;i="5.76,379,1592895600"; d="scan'208";a="502242077" 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:37:41 -0700 To: kirankumark@marvell.com, Thomas Monjalon , Andrew Rybchenko 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: <20200821110330.214931-1-kirankumark@marvell.com> <20200901032708.58247-1-kirankumark@marvell.com> From: Ferruh Yigit Message-ID: Date: Tue, 1 Sep 2020 14:37:38 +0100 MIME-Version: 1.0 In-Reply-To: <20200901032708.58247-1-kirankumark@marvell.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v7 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 9/1/2020 4:27 AM, kirankumark@marvell.com wrote: > From: Kiran Kumar K > > This patch reserves 2 bits as input selection to select Inner and > outer encapsulation level for RSS computation. It is combined with existing > ETH_RSS_* to choose Inner or outer layers. > 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: > * Re-worked to keep it in sync with rte_flow_action_rss and support upto > 3 levels. > * Addressed testpmd review comments. > > 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..13e49bbd7 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. > + * bit 50 and 51 are reserved for this. > + */ > + > +/** level 0, requests the default behavior. Depending on the packet > + * type, it can mean outermost, innermost, anything in between or even no RSS. > + * It basically stands for the innermost encapsulation level RSS > + * can be performed on according to PMD and device capabilities. > + */ > +#define ETH_RSS_LEVEL_0 (0ULL << 50) I can see from history how this is involved, but the 'ETH_RSS_LEVEL_0' naming is not really clear what it is, the naming in v6 is more clear. What about following one: 0 -> LEVEL_PMD_DEFAULT 1 -> LEVEL_OUTER 2 -> LEVEL_INNER 3 -> LEVEL_INNER_OUTER This doesn't exactly match to rte_flow one, but closer than v6 one. This ends with max level 2. And defines a way to say both inner and outer. > + > +/** level 1, requests RSS to be performed on the outermost packet > + * encapsulation level. > + */ > +#define ETH_RSS_LEVEL_1 (1ULL << 50) > + > +/** level 2, requests RSS to be performed on the > + * specified inner packet encapsulation level, from outermost to > + * innermost (lower to higher values). > + */ > +#define ETH_RSS_LEVEL_2 (2ULL << 50) I can see you are trying to copy rte_flow usage, but this doesn't really makes sense here. Where the value of the level is defined in this case? If not defined how the PMD knows which level to use? > +#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 >