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 966C2A0524; Thu, 7 Jan 2021 14:33:40 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 18EA5140F54; Thu, 7 Jan 2021 14:33:40 +0100 (CET) Received: from wnew2-smtp.messagingengine.com (wnew2-smtp.messagingengine.com [64.147.123.27]) by mails.dpdk.org (Postfix) with ESMTP id 55728140F50 for ; Thu, 7 Jan 2021 14:33:39 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.west.internal (Postfix) with ESMTP id AEEBE1672; Thu, 7 Jan 2021 08:33:35 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Thu, 07 Jan 2021 08:33:36 -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= nShiMHuP6wVw/UlEE/4CYXELyTGdVjyv9lHW0QwinPs=; b=WcP8M7lEnVVD8HVF ztcegnaYaMYOcPsQIWzPa0O8KI89XWrNfiQsfUnCW+8S3mWNWNH2vAf66nDfW+X4 hcF3bwwvDHQYjzTnDPD7FuN3Rj+SnRKOm6QEeGiSd2+Z0MzRseAH9douco6e6CPg b80gWetabpByQN0Tk9eCl0CurjFFgcHWVmEpIopRVipMoLqaA7Mqjd9m7vsqhzsX 3Ei/idey+GC0JqYf4usY0Q9vereTgLG7YDEWxnG9/FeA+PLP0Cn3cVJ06ZG1+vsg bxPcZAtdPgkLIyMZJ4NOituuM1N4fQzAMDFBuLts4WwQ4nRVzmFdzDiMQdS6El5D vryP+A== 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=nShiMHuP6wVw/UlEE/4CYXELyTGdVjyv9lHW0Qwin Ps=; b=KP0/4dI1/hKDsDkzyfoRWhQK1QlBM2CoeEHW1O2mFXgf9X+W1HzqbtbyB Kn/HHoQiHS+GDdWI+Zmkx3sXBNCKjrlri4jhV+VtBp8uahAWsam/JaSs8Z503yhd v3aFLAEOuv7UNYCka3A3/Ovd+1M20EZNmWTqcJDa/l0jJ7ptVUBwgaICZ5xr3C/1 N/yHJKSaG9Wj6HI83HFnLOQljjmB6HH2bSKX0yQ4bMqi4vfETidOTaRm2ScLihmo Nid4htdtWbldqU5+Y1xWqhSj4xOrFt1LXirTUOtX2AOZxBDLL64dkBdiLnE+IPDJ qDaOkMs0tGPeznwHsoGur9MQhuNww== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdegvddgheefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepgeejfffhhfeghfetveffgeffteelveekhffghfefgedvleeuveet fffgudelvefhnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucfkphepjeejrddufe egrddvtdefrddukeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghi lhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth 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 5C9E2108005B; Thu, 7 Jan 2021 08:33:33 -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 14:33:31 +0100 Message-ID: <27289607.Vi9ZVq1Shk@thomas> In-Reply-To: References: <20201216085854.7842-1-jia.guo@intel.com> <1693993.jziF1hSf6E@thomas> 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 13:47, Zhang, Qi Z: > > > -----Original Message----- > > From: Thomas Monjalon > > Sent: Thursday, January 7, 2021 6:12 PM > > To: Guo, Jia > > Cc: Zhang, Qi Z ; Wu, Jingjing ; > > Yang, Qiming ; Wang, Haiyue > > ; dev@dpdk.org; Yigit, Ferruh > > ; 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 > > > > 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 > > > > > Reviewed-by: Qi Zhang > > > > [...] > > > > > --- 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? > 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? I still don't see which use case is missing. > > > > 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-compatibility tool shows negative :) , thanks Ferruh' s guide. > https://github.com/ferruhy/dpdk/actions/runs/468859673 That's very strange. An enum value is changed. Why it is not flagged by libabigail? > > > 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.