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 DB12DA04B1; Tue, 8 Sep 2020 21:41:02 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 138524C99; Tue, 8 Sep 2020 21:41:02 +0200 (CEST) Received: from mail-ot1-f65.google.com (mail-ot1-f65.google.com [209.85.210.65]) by dpdk.org (Postfix) with ESMTP id 85BD22BAB for ; Tue, 8 Sep 2020 21:41:00 +0200 (CEST) Received: by mail-ot1-f65.google.com with SMTP id h17so264439otr.1 for ; Tue, 08 Sep 2020 12:41:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3yBuwreBOzkZI3CDgulndwbyn0QypqlVEIlIr90IpJU=; b=GVDdUp6nQB287Pe8I5+QrwPvGM/wD9eRBgxWq8ldajIuxea05PQyH/dtkB15ysXIHH IElDMPk+rc5pSc//aMZLJ/Jn2jo0M09//3d4dhTBwX99gXMGC1iMBBvJRGjsXex0B/Ww R/Sphx0zRXxI1GZ1ZKayNTqN3m/3YoYGjMd/8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3yBuwreBOzkZI3CDgulndwbyn0QypqlVEIlIr90IpJU=; b=aZ2wNOe/lIZg/Leg8+A86CPHuCqeEX5IbapHu5WnPQtmz1w7Mdt8x8wveniXhoqpmB Y8dAPqB2hXvwvD57ambwrp6t57Lg6+G++jEoPTxD9k4wI+Cs4Hz/bAMhnvVkj3B1K1H+ WLvoz/8zcB+VzcG+9YqWf5vr7hA+V7lc5WMXI6p6rG5M9PeiYctcEqGwS/zhcRkIQdki UcikVr82wYsAo4E1neP95X1elbSdHMt4FitklvnI9rnI60tHEBIkboGY80zDbcImQDjd EX+dNfe+NsB2hHm/ut+EBbcg7058HpQOiYl+OJ0R0WOLRAv9+Zsx6a3ZGfI1MPEIkdWG e3bg== X-Gm-Message-State: AOAM533LOzgtAAN2f9OYBYZZciqtd0EfK4qhLY2fodaHPikSL7qmqIwi toLirfdX4HXqESquibCYvI26EUz1Ip+7us4Dp8MqyQ== X-Google-Smtp-Source: ABdhPJzmhDnZfJSfmzZ/mvAERCmYospZhsbujM8XyjffhSd/jNogq4ubFaoYRSL062oKHAvFj3tDzLZ9qCbmyiTghQc= X-Received: by 2002:a05:6830:1e0a:: with SMTP id s10mr438070otr.95.1599594059632; Tue, 08 Sep 2020 12:40:59 -0700 (PDT) MIME-Version: 1.0 References: <20200821110330.214931-1-kirankumark@marvell.com> <20200901032708.58247-1-kirankumark@marvell.com> <6fc71450-ffae-1ddb-e0bb-c0c8864f6a28@intel.com> <27823143-3cec-073a-385a-2e5b0485f078@solarflare.com> In-Reply-To: <27823143-3cec-073a-385a-2e5b0485f078@solarflare.com> From: Ajit Khaparde Date: Tue, 8 Sep 2020 12:40:43 -0700 Message-ID: To: Andrew Rybchenko Cc: Ferruh Yigit , Kiran Kumar Kokkilagadda , Thomas Monjalon , "dev@dpdk.org" , Jerin Jacob Kollanukkaran , "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" , Rasesh Mody , Shahed Shaikh , Nithin Kumar Dabilpuram , "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" , Liron Himi , "jingjing.wu@intel.com" , "xavier.huwei@huawei.com" , "humin29@huawei.com" , "yisen.zhuang@huawei.com" , "somnath.kotur@broadcom.com" , "jasvinder.singh@intel.com" , "cristian.dumitrescu@intel.com" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [EXT] Re: [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 Mon, Sep 7, 2020 at 1:12 AM Andrew Rybchenko wrote: > On 9/3/20 4:14 PM, Ferruh Yigit wrote: > > On 9/3/2020 11:11 AM, Kiran Kumar Kokkilagadda wrote: > >> *From:* Ajit Khaparde > >> *Sent:* Tuesday, September 1, 2020 10:42 PM > >> *To:* Kiran Kumar Kokkilagadda > >> *Cc:* Ferruh Yigit ; Thomas Monjalon > >> ; Andrew Rybchenko ; > >> dev@dpdk.org; Jerin Jacob Kollanukkaran ; > >> 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; Rasesh > >> Mody ; Shahed Shaikh ; Nithin > >> Kumar Dabilpuram ; 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; Liron Himi > >> ; jingjing.wu@intel.com; xavier.huwei@huawei.com; > >> humin29@huawei.com; yisen.zhuang@huawei.com; > >> somnath.kotur@broadcom.com; jasvinder.singh@intel.com; > >> cristian.dumitrescu@intel.com > >> *Subject:* Re: [EXT] Re: [dpdk-dev][PATCH v7 1/3] ethdev: add level > >> support for RSS offload types > >> > >> On Tue, Sep 1, 2020 at 7:27 AM Kiran Kumar Kokkilagadda > >> > wrote: > >> > >> > >> > >> > -----Original Message----- > >> > From: Ferruh Yigit >> > > >> > Sent: Tuesday, September 1, 2020 7:08 PM > >> > To: Kiran Kumar Kokkilagadda >> >; Thomas Monjalon > >> > >; Andrew > >> Rybchenko > >> > > >> > Cc: dev@dpdk.org ; Jerin Jacob > Kollanukkaran > >> >; > >> > 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 > >> ; Rasesh Mody > >> > >; Shahed Shaikh > >> >; Nithin Kumar > >> > Dabilpuram >> >; > >> 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 ; Liron Himi > >> > >; > >> 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 > > >> > Subject: [EXT] Re: [dpdk-dev][PATCH v7 1/3] ethdev: add level > >> support for RSS > >> > offload types > >> > > >> > External Email > >> > > >> > > >> ---------------------------------------------------------------------- > >> > 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. > >> > >> This one looks good to me. If everyone is ok with the proposed > >> changes, I > >> will send V8. > >> > >> How about following one: > >> 0 -> LEVEL_PMD_DEFAULT > >> 1 -> LEVEL_OUTERMOST > >> 2 -> LEVEL_INNERMOST > >> > >> This way we can avoid any ambiguity especially if stacked tunnel > >> headersbecome real. > >> > >> > >> 3 -> LEVEL_INNER_OUTER > >> > >> But I am not sure if INNER_OUTER has a use case. > >> > >> Alternatively, > >> > >> why not just add uint32_t level; > >> > >> just like in case of rte_flow_action_rss? > >> > >> It will break ABI but its 20.11. > >> > >> Thanks > >> > >> -Ajit > >> > >> Can I send V8 with this proposal? > >> > >> 0 -> LEVEL_PMD_DEFAULT > >> 1 -> LEVEL_OUTERMOST > >> 2 -> LEVEL_INNERMOST > >> > >> If anyone want INNER_OUTER, they can specify LEVEL_OUTERMOST| > >> LEVEL_INNERMOST > > > > +1 to INNERMOST & OUTERMOST, and use "LEVEL_OUTERMOST| LEVEL_INNERMOST" > > for INNER_OUTER. > > Frankly speaking I'd drop OUTERMOST | INNERMOST for now in requested RSS > hash config and defined OUTERMOST | INNERMOST in > capabilities as possibility to hash by either INNERMOST or > OUTERMOST headers correspondingly. > > > > > But the capability reporting is still problematic. > > If @Andrew has no objection, I think it is ok to have a v8 and we can > > continue discussion on it. > > See above. Number of recognized tunnel levels could be reported > in dev_info, but looks insufficient, since it is interesting > which tunnels are supported (may be even on which level). > +1. > > >> > >> > >> > > >> > > + > >> > > +/** 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 > >> > > > >> > >