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 DE797A0524; Thu, 7 Jan 2021 13:48:02 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 68FB7140F50; Thu, 7 Jan 2021 13:48:02 +0100 (CET) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by mails.dpdk.org (Postfix) with ESMTP id F3BB9140F4F for ; Thu, 7 Jan 2021 13:47:59 +0100 (CET) IronPort-SDR: z1PrUpWf/9g0zEBijm3SudYNxnomn1wGr3FFz4ibsR6m+7ydxfx0AtN4i2HvBXttrwB3rg5UOR 8uzbt4tieKWQ== X-IronPort-AV: E=McAfee;i="6000,8403,9856"; a="174840841" X-IronPort-AV: E=Sophos;i="5.79,329,1602572400"; d="scan'208";a="174840841" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jan 2021 04:47:58 -0800 IronPort-SDR: cRuOrg2+2DyFRv/yBBQG2pHhnWBVLUjunUmlnBin6rsLiMsJ+UBk1IdMV7zNDzUynAew6ARX9E RGlC1DPIuSjg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.79,329,1602572400"; d="scan'208";a="463025597" Received: from fmsmsx602.amr.corp.intel.com ([10.18.126.82]) by fmsmga001.fm.intel.com with ESMTP; 07 Jan 2021 04:47:58 -0800 Received: from shsmsx605.ccr.corp.intel.com (10.109.6.215) by fmsmsx602.amr.corp.intel.com (10.18.126.82) 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 04:47:57 -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 20:47:56 +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 20:47:56 +0800 From: "Zhang, Qi Z" To: Thomas Monjalon , "Guo, Jia" CC: "Wu, Jingjing" , "Yang, Qiming" , "Wang, Haiyue" , "dev@dpdk.org" , "Yigit, Ferruh" , "andrew.rybchenko@oktetlabs.ru" , "orika@nvidia.com" , "getelson@nvidia.com" Thread-Topic: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri Thread-Index: AQHW2cLnLDO52W/MnUi6XmgEhPhIWqoauFcAgAC+FICAAAryAIAAqDkQ Date: Thu, 7 Jan 2021 12:47:55 +0000 Message-ID: References: <20201216085854.7842-1-jia.guo@intel.com> <8091331.oFBQTsvStG@thomas> <1693993.jziF1hSf6E@thomas> In-Reply-To: <1693993.jziF1hSf6E@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > -----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 >=20 > 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. >=20 > 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_p= ort_add=20 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 pars= er 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... 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 un= less 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 >=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-compatibility t= ool shows negative :) , thanks Ferruh' s guide. https://github.com/ferruhy/dpdk/actions/runs/468859673 Thanks Qi > > > > 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