From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
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 <dev@dpdk.org>; Tue, 8 Sep 2020 21:41:00 +0200 (CEST)
Received: by mail-ot1-f65.google.com with SMTP id h17so264439otr.1
for <dev@dpdk.org>; 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>
<ba39461a-cbc8-519b-bc9c-e52f2f7abc4b@intel.com>
<BYAPR18MB2965E0C92CD27F91B763DF81AC2E0@BYAPR18MB2965.namprd18.prod.outlook.com>
<CACZ4nhvAWFWqsfnqDn4h2MsgYVNYvC_2E++xDqsi4n3351eGQg@mail.gmail.com>
<BYAPR18MB29651513D12F2642CC190CDFAC2C0@BYAPR18MB2965.namprd18.prod.outlook.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 <ajit.khaparde@broadcom.com>
Date: Tue, 8 Sep 2020 12:40:43 -0700
Message-ID: <CACZ4nhsMAU3J5MrBb0Ubdh+ZxpA8N7s0_w4-mTbegCFGT+WY-A@mail.gmail.com>
To: Andrew Rybchenko <arybchenko@solarflare.com>
Cc: Ferruh Yigit <ferruh.yigit@intel.com>,
Kiran Kumar Kokkilagadda <kirankumark@marvell.com>,
Thomas Monjalon <thomas@monjalon.net>,
"dev@dpdk.org" <dev@dpdk.org>, Jerin Jacob Kollanukkaran <jerinj@marvell.com>,
"orika@mellanox.com" <orika@mellanox.com>,
"xuanziyang2@huawei.com" <xuanziyang2@huawei.com>,
"cloud.wangxiaoyun@huawei.com" <cloud.wangxiaoyun@huawei.com>,
"zhouguoyang@huawei.com" <zhouguoyang@huawei.com>,
"rosen.xu@intel.com" <rosen.xu@intel.com>,
"beilei.xing@intel.com" <beilei.xing@intel.com>,
"jia.guo@intel.com" <jia.guo@intel.com>,
Rasesh Mody <rmody@marvell.com>, Shahed Shaikh <shshaikh@marvell.com>,
Nithin Kumar Dabilpuram <ndabilpuram@marvell.com>,
"qiming.yang@intel.com" <qiming.yang@intel.com>,
"qi.z.zhang@intel.com" <qi.z.zhang@intel.com>,
"keith.wiles@intel.com" <keith.wiles@intel.com>,
"hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>,
"sachin.saxena@nxp.com" <sachin.saxena@nxp.com>,
"wei.zhao1@intel.com" <wei.zhao1@intel.com>,
"johndale@cisco.com" <johndale@cisco.com>,
"hyonkim@cisco.com" <hyonkim@cisco.com>, "chas3@att.com" <chas3@att.com>,
"matan@mellanox.com" <matan@mellanox.com>,
"shahafs@mellanox.com" <shahafs@mellanox.com>,
"viacheslavo@mellanox.com" <viacheslavo@mellanox.com>,
"rahul.lakkireddy@chelsio.com" <rahul.lakkireddy@chelsio.com>,
"grive@u256.net" <grive@u256.net>, Liron Himi <lironh@marvell.com>,
"jingjing.wu@intel.com" <jingjing.wu@intel.com>,
"xavier.huwei@huawei.com" <xavier.huwei@huawei.com>,
"humin29@huawei.com" <humin29@huawei.com>,
"yisen.zhuang@huawei.com" <yisen.zhuang@huawei.com>,
"somnath.kotur@broadcom.com" <somnath.kotur@broadcom.com>,
"jasvinder.singh@intel.com" <jasvinder.singh@intel.com>,
"cristian.dumitrescu@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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
On Mon, Sep 7, 2020 at 1:12 AM Andrew Rybchenko <arybchenko@solarflare.com>
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 <ajit.khaparde@broadcom.com>
> >> *Sent:* Tuesday, September 1, 2020 10:42 PM
> >> *To:* Kiran Kumar Kokkilagadda <kirankumark@marvell.com>
> >> *Cc:* Ferruh Yigit <ferruh.yigit@intel.com>; Thomas Monjalon
> >> <thomas@monjalon.net>; Andrew Rybchenko <arybchenko@solarflare.com>;
> >> dev@dpdk.org; Jerin Jacob Kollanukkaran <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; Rasesh
> >> Mody <rmody@marvell.com>; Shahed Shaikh <shshaikh@marvell.com>; Nithin
> >> Kumar Dabilpuram <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; Liron Himi
> >> <lironh@marvell.com>; 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
> >> <kirankumark@marvell.com <mailto:kirankumark@marvell.com>> wrote:
> >>
> >>
> >>
> >> > -----Original Message-----
> >> > From: Ferruh Yigit <ferruh.yigit@intel.com
> >> <mailto:ferruh.yigit@intel.com>>
> >> > Sent: Tuesday, September 1, 2020 7:08 PM
> >> > To: Kiran Kumar Kokkilagadda <kirankumark@marvell.com
> >> <mailto:kirankumark@marvell.com>>; Thomas Monjalon
> >> > <thomas@monjalon.net <mailto:thomas@monjalon.net>>; Andrew
> >> Rybchenko
> >> <arybchenko@solarflare.com <mailto:arybchenko@solarflare.com>>
> >> > Cc: dev@dpdk.org <mailto:dev@dpdk.org>; Jerin Jacob
> Kollanukkaran
> >> <jerinj@marvell.com <mailto:jerinj@marvell.com>>;
> >> > orika@mellanox.com <mailto:orika@mellanox.com>;
> >> xuanziyang2@huawei.com
> >> <mailto:xuanziyang2@huawei.com>;
> >> > cloud.wangxiaoyun@huawei.com
> >> <mailto:cloud.wangxiaoyun@huawei.com>;
> >> zhouguoyang@huawei.com <mailto:zhouguoyang@huawei.com>;
> >> > rosen.xu@intel.com <mailto:rosen.xu@intel.com>;
> >> beilei.xing@intel.com
> >> <mailto:beilei.xing@intel.com>; jia.guo@intel.com
> >> <mailto:jia.guo@intel.com>; Rasesh Mody
> >> > <rmody@marvell.com <mailto:rmody@marvell.com>>; Shahed Shaikh
> >> <shshaikh@marvell.com <mailto:shshaikh@marvell.com>>; Nithin Kumar
> >> > Dabilpuram <ndabilpuram@marvell.com
> >> <mailto:ndabilpuram@marvell.com>>;
> >> qiming.yang@intel.com <mailto:qiming.yang@intel.com>;
> >> > qi.z.zhang@intel.com <mailto:qi.z.zhang@intel.com>;
> >> keith.wiles@intel.com
> >> <mailto:keith.wiles@intel.com>; hemant.agrawal@nxp.com
> >> <mailto:hemant.agrawal@nxp.com>;
> >> > sachin.saxena@nxp.com <mailto:sachin.saxena@nxp.com>;
> >> wei.zhao1@intel.com
> >> <mailto:wei.zhao1@intel.com>; johndale@cisco.com
> >> <mailto:johndale@cisco.com>;
> >> > hyonkim@cisco.com <mailto:hyonkim@cisco.com>; chas3@att.com
> >> <mailto:chas3@att.com>; matan@mellanox.com
> >> <mailto:matan@mellanox.com>;
> >> > shahafs@mellanox.com <mailto:shahafs@mellanox.com>;
> >> viacheslavo@mellanox.com <mailto:viacheslavo@mellanox.com>;
> >> > rahul.lakkireddy@chelsio.com
> >> <mailto:rahul.lakkireddy@chelsio.com>;
> >> grive@u256.net <mailto:grive@u256.net>; Liron Himi
> >> > <lironh@marvell.com <mailto:lironh@marvell.com>>;
> >> jingjing.wu@intel.com
> >> <mailto:jingjing.wu@intel.com>; xavier.huwei@huawei.com
> >> <mailto:xavier.huwei@huawei.com>;
> >> > humin29@huawei.com <mailto:humin29@huawei.com>;
> >> yisen.zhuang@huawei.com
> >> <mailto:yisen.zhuang@huawei.com>;
> >> > ajit.khaparde@broadcom.com <mailto:ajit.khaparde@broadcom.com>;
> >> somnath.kotur@broadcom.com <mailto:somnath.kotur@broadcom.com>;
> >> > jasvinder.singh@intel.com <mailto:jasvinder.singh@intel.com>;
> >> cristian.dumitrescu@intel.com <mailto: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
> >> <mailto:kirankumark@marvell.com> wrote:
> >> > > From: Kiran Kumar K <kirankumark@marvell.com
> >> <mailto:kirankumark@marvell.com>>
> >> > >
> >> > > 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 <kirankumark@marvell.com
> >> <mailto:kirankumark@marvell.com>>
> >> > > ---
> >> > > 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
> >> > >
> >>
>
>