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 B9BF3A0524; Thu, 7 Jan 2021 10:32:40 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4F0DB140F0D; Thu, 7 Jan 2021 10:32:40 +0100 (CET) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by mails.dpdk.org (Postfix) with ESMTP id 664E6140F0B for ; Thu, 7 Jan 2021 10:32:38 +0100 (CET) IronPort-SDR: RHooIAZVfztkuJ7pA2HMRMMoRYwELcpWaOxKyHNZyBujduUkKDOLsah5ceP3JJsJBGGlTNC6de zLmMO8qeWdNA== X-IronPort-AV: E=McAfee;i="6000,8403,9856"; a="177553326" X-IronPort-AV: E=Sophos;i="5.79,329,1602572400"; d="scan'208";a="177553326" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jan 2021 01:32:37 -0800 IronPort-SDR: Zmz5SW9oj72FBmmdZF8l0zi2H02wzE1GmBz6WzO4yvCmDBy6J59bgH9o4GYZgzHrd8XNaskfcY +Hq46H0Ga85Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.79,329,1602572400"; d="scan'208";a="351199603" Received: from fmsmsx603.amr.corp.intel.com ([10.18.126.83]) by fmsmga008.fm.intel.com with ESMTP; 07 Jan 2021 01:32:36 -0800 Received: from shsmsx603.ccr.corp.intel.com (10.109.6.143) 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 01:32:35 -0800 Received: from shsmsx601.ccr.corp.intel.com (10.109.6.141) by SHSMSX603.ccr.corp.intel.com (10.109.6.143) 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 17:32:34 +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 17:32:34 +0800 From: "Guo, Jia" To: Thomas Monjalon CC: "Zhang, Qi Z" , "Wu, Jingjing" , "Yang, Qiming" , "Wang, Haiyue" , "dev@dpdk.org" , "Yigit, Ferruh" , "andrew.rybchenko@oktetlabs.ru" Thread-Topic: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri Thread-Index: AQHW2cLntBoLNgS2KkulxwIL0AdqIaoauFcAgAFB0CA= Date: Thu, 7 Jan 2021 09:32:33 +0000 Message-ID: References: <20201216085854.7842-1-jia.guo@intel.com> <20201224065940.76857-1-jia.guo@intel.com> <20201224065940.76857-2-jia.guo@intel.com> <8091331.oFBQTsvStG@thomas> In-Reply-To: <8091331.oFBQTsvStG@thomas> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.5.1.3 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 AM > To: Guo, Jia > Cc: Zhang, Qi Z ; Wu, Jingjing > ; Yang, Qiming ; Wang, > Haiyue ; dev@dpdk.org; Yigit, Ferruh > ; andrew.rybchenko@oktetlabs.ru > Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for > ecpri >=20 > 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, > > }; >=20 > 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. >=20 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 b= y rte_flow right now. > Sorry, it is a nack. > BTW, it is probably breaking the ABI because of RTE_TUNNEL_TYPE_MAX. >=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 >=20 Thanks for your helpful tip.