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 37C92A0524;
Thu, 7 Jan 2021 17:59:02 +0100 (CET)
Received: from [217.70.189.124] (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id 21E3E140F9C;
Thu, 7 Jan 2021 17:59:02 +0100 (CET)
Received: from wnew3-smtp.messagingengine.com (wnew3-smtp.messagingengine.com
[64.147.123.17])
by mails.dpdk.org (Postfix) with ESMTP id 6D903140F98
for <dev@dpdk.org>; Thu, 7 Jan 2021 17:59:00 +0100 (CET)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42])
by mailnew.west.internal (Postfix) with ESMTP id 9C0A01672;
Thu, 7 Jan 2021 11:58:58 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163])
by compute2.internal (MEProxy); Thu, 07 Jan 2021 11:58:59 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h=
from:to:cc:subject:date:message-id:in-reply-to:references
:mime-version:content-transfer-encoding:content-type; s=fm3; bh=
1YBopoNcUYI7ebHt0NR4PWU4fsiss1fchmZACvl9pfs=; b=eH//LFuxiSlru/8s
Zm43DcdbuBMBli5ApAml8kt56qaAezFhdVQSeIHm8gpfEmahBsAqQZclpMKCovfi
YpsJcnddZCR+LSA3vuhpeh6fLM/KeeHPoMjOxdjGLhXhfrub1s9Jxhjy5NB7uLzH
QOvzE+igAMZMvRusNmTWPzkZ949YdWr4GsvXfq3xz3dM5bBihK/yMVATQI7RTk9L
2AfQvlmuDw8BxqJa43MTJn1LNH1nRCdvCjKiMRrRhhTvNyzqlayySxAFt01HFsOA
MmL+e2FOSJBAUAhBg1r5juMWDgILUcmlgaYplZpP40SRmJczw4I+C/IFE4QC5zBc
pOBKKg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=cc:content-transfer-encoding:content-type
:date:from:in-reply-to:message-id:mime-version:references
:subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender
:x-sasl-enc; s=fm1; bh=1YBopoNcUYI7ebHt0NR4PWU4fsiss1fchmZACvl9p
fs=; b=Z+OjXYWwCMQ/auqYcJVKEACHsopU6XNOhoEoE/yk0Tsq/tyBeE0aPYVIZ
o0GAyiiNYP+K2yudG5mX2wzMFYhPNf4nliQTzlj+JvhsipPRZglIqwCz5JX2jFoV
bgvOQScEvgzMypoA79eBwBONqx+9+rype5yuqxfghJ+NBv9OM4tUXHMtKDe3UF5R
0h3kgmAr+1Mmz+uASew0C3DfxSfQzy+vUVIR07EqibpRKzCMAZ404a0k92yjarrb
Js6nIeAc66HXDGjdV4YbSfdWq3wsBQ/uKyUcLXa093375S5CFTDYAyqAXZs2mVd7
9zBLU9Aks/epLgKlA8Y60RptNf8bg==
X-ME-Sender: <xms:0T33X5T-hl5f-xkqB87QZ003fdXpg74nugPXmNjGP0vvo54jZYO1Pg>
<xme:0T33Xyx5mdi2bDv2F5lnhX2Wl85XCnPmkunp1z1Pjf4LeQo6kmg3z_M8-YwY0tYNH
bUfvXQO2Unru0MC7g>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdegvddgleehucetufdoteggodetrfdotf
fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr
shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg
ftrfgrthhtvghrnhepfeelheeiteettefgudekteeihfeitefgvdefhfdtvdeifefggfeh
teeffeduueefnecuffhomhgrihhnpehivghtfhdrohhrghenucfkphepjeejrddufeegrd
dvtdefrddukeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf
rhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth
X-ME-Proxy: <xmx:0T33X-13JvC__1f4uahERNlUw6xnFVPn_cGVKwQQLmmjZSkqBqtYiA>
<xmx:0T33XxBqfylJVKSf-WTIvoAEKpr-QLP2t9szIGuz0mHa26kP8pJi2Q>
<xmx:0T33XyhNjgeavJY7sJmhL7Oz8ch9FRIpjIIKxps6aZa8IJj2QEj9aA>
<xmx:0j33X7U1x7UvO762As2F0VIoYXFmwZV3Vx8DyLEDqn8ghkLMv7wF7LPBI9s>
Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184])
by mail.messagingengine.com (Postfix) with ESMTPA id 9A382108005C;
Thu, 7 Jan 2021 11:58:56 -0500 (EST)
From: Thomas Monjalon <thomas@monjalon.net>
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" <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>
Date: Thu, 07 Jan 2021 17:58:53 +0100
Message-ID: <2049408.mdQoWhQ2pd@thomas>
In-Reply-To: <87efb4f6a3554bf4b2bba5a495efccb0@intel.com>
References: <20201216085854.7842-1-jia.guo@intel.com>
<27289607.Vi9ZVq1Shk@thomas> <87efb4f6a3554bf4b2bba5a495efccb0@intel.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
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>
07/01/2021 16:24, Zhang, Qi Z:
> From: Thomas Monjalon <thomas@monjalon.net>
> > 07/01/2021 13:47, Zhang, Qi Z:
> > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > 07/01/2021 10:32, Guo, Jia:
> > > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > > > 24/12/2020 07:59, Jeff Guo:
> > > > > > > --- 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...
> >
> > I don't understand how it helps to identify an UDP port if there is no rule for
> > this tunnel.
> > What is the usage?
>
> Yes, in general It is a rule, it matches a udp packet's dst port and the action is "now the packet is identified as vxlan packet" then all other rte_flow 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. ( RFC 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."
Yes the port number is free.
But isn't it more natural to specify this port number
as part of the rte_flow rule?