From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (xvm-189-124.dc0.ghst.net [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id 34D0DA0524;
Thu, 7 Jan 2021 16:24:29 +0100 (CET)
Received: from [217.70.189.124] (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id 18937140FD8;
Thu, 7 Jan 2021 16:24:29 +0100 (CET)
Received: from mga09.intel.com (mga09.intel.com [134.134.136.24])
by mails.dpdk.org (Postfix) with ESMTP id 394DA140FD4
for <dev@dpdk.org>; Thu, 7 Jan 2021 16:24:27 +0100 (CET)
IronPort-SDR: iY8fJa/Znp9IFPcOHkuDwPb3z1OLkX7OjffgJyUUCFRKRHYra37mvnTtgbnol/CZGow9Kk9EKU
jJ96YNRsJ/4Q==
X-IronPort-AV: E=McAfee;i="6000,8403,9857"; a="177589568"
X-IronPort-AV: E=Sophos;i="5.79,329,1602572400"; d="scan'208";a="177589568"
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
07 Jan 2021 07:24:25 -0800
IronPort-SDR: zmMu2vVKlMsmIe78QWPvVX6NC4mLN8FkY/odhFxc9CJZD3F64IuGvr9DtzAdYbzEj9UmtGjjJV
Gsquz3jZQEnA==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.79,329,1602572400"; d="scan'208";a="403057161"
Received: from fmsmsx603.amr.corp.intel.com ([10.18.126.83])
by FMSMGA003.fm.intel.com with ESMTP; 07 Jan 2021 07:24:25 -0800
Received: from shsmsx605.ccr.corp.intel.com (10.109.6.215) by
fmsmsx603.amr.corp.intel.com (10.18.126.83) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
15.1.1713.5; Thu, 7 Jan 2021 07:24:24 -0800
Received: from shsmsx601.ccr.corp.intel.com (10.109.6.141) by
SHSMSX605.ccr.corp.intel.com (10.109.6.215) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
15.1.1713.5; Thu, 7 Jan 2021 23:24:22 +0800
Received: from shsmsx601.ccr.corp.intel.com ([10.109.6.141]) by
SHSMSX601.ccr.corp.intel.com ([10.109.6.141]) with mapi id 15.01.1713.004;
Thu, 7 Jan 2021 23:24:22 +0800
From: "Zhang, Qi Z" <qi.z.zhang@intel.com>
To: Thomas Monjalon <thomas@monjalon.net>, "Guo, Jia" <jia.guo@intel.com>
CC: "Wu, Jingjing" <jingjing.wu@intel.com>, "Yang, Qiming"
<qiming.yang@intel.com>, "Wang, Haiyue" <haiyue.wang@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>, "Yigit, Ferruh" <ferruh.yigit@intel.com>,
"andrew.rybchenko@oktetlabs.ru" <andrew.rybchenko@oktetlabs.ru>,
"orika@nvidia.com" <orika@nvidia.com>, "getelson@nvidia.com"
<getelson@nvidia.com>, Dodji Seketeli <dodji@redhat.com>
Thread-Topic: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for
ecpri
Thread-Index: AQHW2cLnLDO52W/MnUi6XmgEhPhIWqoauFcAgAC+FICAAAryAIAAqDkQ//+QKICAAIuhsA==
Date: Thu, 7 Jan 2021 15:24:22 +0000
Message-ID: <87efb4f6a3554bf4b2bba5a495efccb0@intel.com>
References: <20201216085854.7842-1-jia.guo@intel.com>
<1693993.jziF1hSf6E@thomas> <b85515ea6be742bca9cb8d33c9f2de9a@intel.com>
<27289607.Vi9ZVq1Shk@thomas>
In-Reply-To: <27289607.Vi9ZVq1Shk@thomas>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-reaction: no-action
dlp-version: 11.5.1.3
dlp-product: dlpe-windows
x-originating-ip: [10.239.127.36]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for
ecpri
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
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>
> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Thursday, January 7, 2021 9:34 PM
> To: Guo, Jia <jia.guo@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>
> Cc: Wu, Jingjing <jingjing.wu@intel.com>; Yang, Qiming
> <qiming.yang@intel.com>; Wang, Haiyue <haiyue.wang@intel.com>;
> dev@dpdk.org; Yigit, Ferruh <ferruh.yigit@intel.com>;
> andrew.rybchenko@oktetlabs.ru; orika@nvidia.com; getelson@nvidia.com;
> Dodji Seketeli <dodji@redhat.com>
> Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for=
ecpri
>=20
> 07/01/2021 13:47, Zhang, Qi Z:
> >
> > > -----Original Message-----
> > > From: Thomas Monjalon <thomas@monjalon.net>
> > > Sent: Thursday, January 7, 2021 6:12 PM
> > > To: Guo, Jia <jia.guo@intel.com>
> > > Cc: Zhang, Qi Z <qi.z.zhang@intel.com>; Wu, Jingjing
> > > <jingjing.wu@intel.com>; Yang, Qiming <qiming.yang@intel.com>; Wang,
> > > Haiyue <haiyue.wang@intel.com>; dev@dpdk.org; Yigit, Ferruh
> > > <ferruh.yigit@intel.com>; andrew.rybchenko@oktetlabs.ru;
> > > orika@nvidia.com; getelson@nvidia.com
> > > Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel
> > > type for ecpri
> > >
> > > 07/01/2021 10:32, Guo, Jia:
> > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > > 24/12/2020 07:59, Jeff Guo:
> > > > > > Add type of RTE_TUNNEL_TYPE_ECPRI into the enum of ethdev
> > > > > > tunnel
> > > > > type.
> > > > > >
> > > > > > Signed-off-by: Jeff Guo <jia.guo@intel.com>
> > > > > > Reviewed-by: Qi Zhang <qi.z.zhang@intel.com>
> > > > > [...]
> > > > > > --- a/lib/librte_ethdev/rte_ethdev.h
> > > > > > +++ b/lib/librte_ethdev/rte_ethdev.h
> > > > > > @@ -1219,6 +1219,7 @@ enum rte_eth_tunnel_type {
> > > > > > RTE_TUNNEL_TYPE_IP_IN_GRE,
> > > > > > RTE_L2_TUNNEL_TYPE_E_TAG,
> > > > > > RTE_TUNNEL_TYPE_VXLAN_GPE,
> > > > > > + RTE_TUNNEL_TYPE_ECPRI,
> > > > > > RTE_TUNNEL_TYPE_MAX,
> > > > > > };
> > > > >
> > > > > We tried to remove all these legacy API in DPDK 20.11.
> > > > > Andrew decided to not remove this one because it is not yet
> > > > > completely replaced by rte_flow in all drivers.
> > > > > However, I am against continuing to update this API.
> > > > > The opposite work should be done: migrate to rte_flow.
> > > >
> > > > Agree but seems that the legacy api and driver legacy
> > > > implementation still keep in this release, and there is no a
> > > > general way to replace the legacy by rte_flow right now.
> > >
> > > I think rte_flow is a complete replacement with more features.
> >
> > Thomas, I may not agree with this.
> >
> > Actually the "enum rte_eth_tunnel_type" is used by
> > rte_eth_dev_udp_tunnel_port_add A packet with specific dst udp port
> > will be recognized as a specific tunnel packet type (e.g. vxlan, vxlan-=
gpe,
> ecpri...) In Intel NIC, the API actually changes the configuration of the=
packet
> parser in HW but not add a filter rule and I guess all other devices may =
enable it
> in a similar way.
> > so naturally it should be a device (port) level configuration but not a=
rte_flow
> rule for match, encap, decap...
>=20
> I don't understand how it helps to identify an UDP port if there is no ru=
le for
> this tunnel.
> What is the usage?
Yes, in general It is a rule, it matches a udp packet's dst port and the ac=
tion is "now the packet is identified as vxlan packet" then all other rte_f=
low rules that match for a vlxan as pattern will take effect. but somehow,=
I think they are not rules in the same domain, just like we have dedicate =
API for mac/vlan filter, we'd better have a dedicate API for this also. ( R=
FC for Vxlan explains why we need this. https://tools.ietf.org/html/rfc7348=
).
"Destination Port: IANA has assigned the value 4789 for the
VXLAN UDP port, and this value SHOULD be used by default as the
destination UDP port. Some early implementations of VXLAN have
used other values for the destination port. To enable
interoperability with these implementations, the destination
port SHOULD be configurable."
Thanks
Qi
>=20
> > So I think it's not a good idea to replace the
> > rte_eth_dev_udp_tunnel_port_add with rte_flow config and also there is
> > no existing rte_flow_action can cover this requirement unless we
> > introduce some new one.
> >
> > > You can match, encap, decap.
> > > There is even a new API to get tunnel infos after decap.
> > > What is missing?
>=20
> I still don't see which use case is missing.
>=20
>=20
> > > > > Sorry, it is a nack.
> > > > > BTW, it is probably breaking the ABI because of
> RTE_TUNNEL_TYPE_MAX.
> >
> > Yes that may break the ABI but fortunately the checking-abi-compatibili=
ty tool
> shows negative :) , thanks Ferruh' s guide.
> > https://github.com/ferruhy/dpdk/actions/runs/468859673
>=20
> That's very strange. An enum value is changed.
> Why it is not flagged by libabigail?
>=20
>=20
> > > > Oh, the ABI break should be a problem.
> > > >
> > > > > PS: please Cc ethdev maintainers for such patch, thanks.
> > > > > tip: use --cc-cmd devtools/get-maintainer.sh
> > > >
> > > > Thanks for your helpful tip.
>=20
>=20