From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 ; 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: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdegvddgleehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepfeelheeiteettefgudekteeihfeitefgvdefhfdtvdeifefggfeh teeffeduueefnecuffhomhgrihhnpehivghtfhdrohhrghenucfkphepjeejrddufeegrd dvtdefrddukeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf rhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: 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 To: "Guo, Jia" , "Zhang, Qi Z" Cc: "Wu, Jingjing" , "Yang, Qiming" , "Wang, Haiyue" , "dev@dpdk.org" , "Yigit, Ferruh" , "andrew.rybchenko@oktetlabs.ru" , "orika@nvidia.com" , "getelson@nvidia.com" , Dodji Seketeli 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 07/01/2021 16:24, Zhang, Qi Z: > From: Thomas Monjalon > > 07/01/2021 13:47, Zhang, Qi Z: > > > From: Thomas Monjalon > > > > 07/01/2021 10:32, Guo, Jia: > > > > > From: Thomas Monjalon > > > > > > 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?