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 55EC6A0524; Fri, 8 Jan 2021 02:41:25 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 06BE7140DBD; Fri, 8 Jan 2021 02:41:24 +0100 (CET) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by mails.dpdk.org (Postfix) with ESMTP id 48353140DCA for ; Fri, 8 Jan 2021 02:41:22 +0100 (CET) IronPort-SDR: IltDcZy5M0FHh6yrVME1ZJffIYFwkegtz2fvoJoPyd9pidNm3+93F6dbj2xVq/5ltUc9cx1B9F rMp9oL4BmDVg== X-IronPort-AV: E=McAfee;i="6000,8403,9857"; a="176747954" X-IronPort-AV: E=Sophos;i="5.79,330,1602572400"; d="scan'208";a="176747954" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jan 2021 17:41:20 -0800 IronPort-SDR: B4zTx9y8LnAQlHjtTrN8UJl1xPkhLCLJ7JzFm66T/9AapZmiuiGOEVKIqoBaXyxTFvQ7Nv2zG5 /PZat/cHEKtw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.79,330,1602572400"; d="scan'208";a="379937622" Received: from fmsmsx606.amr.corp.intel.com ([10.18.126.86]) by orsmga008.jf.intel.com with ESMTP; 07 Jan 2021 17:41:20 -0800 Received: from shsmsx604.ccr.corp.intel.com (10.109.6.214) by fmsmsx606.amr.corp.intel.com (10.18.126.86) 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:41:19 -0800 Received: from shsmsx601.ccr.corp.intel.com (10.109.6.141) by SHSMSX604.ccr.corp.intel.com (10.109.6.214) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Fri, 8 Jan 2021 09:41:17 +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; Fri, 8 Jan 2021 09:41:17 +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" , Dodji Seketeli Thread-Topic: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri Thread-Index: AQHW2cLnLDO52W/MnUi6XmgEhPhIWqoauFcAgAC+FICAAAryAIAAqDkQ//+QKICAAIuhsP//rcCAgAEHCvA= Date: Fri, 8 Jan 2021 01:41:17 +0000 Message-ID: <3979f8a247474b64a9c7f6fcd84b9c4f@intel.com> References: <20201216085854.7842-1-jia.guo@intel.com> <27289607.Vi9ZVq1Shk@thomas> <87efb4f6a3554bf4b2bba5a495efccb0@intel.com> <2049408.mdQoWhQ2pd@thomas> In-Reply-To: <2049408.mdQoWhQ2pd@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: Friday, January 8, 2021 12:59 AM > 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 > Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for= ecpri >=20 > 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 th= e action is > "now the packet is identified as vxlan packet" then all other rte_flow ru= les 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 w= hy 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." >=20 > Yes the port number is free. > But isn't it more natural to specify this port number as part of the rte_= flow > rule? I think if we have a rte_flow action type that can be used to set a packet'= s tunnel type xxx, like below=20 #flow create eth/ipv4/udp port is 4789/... action set_tunnel_type VxLAN / e= nd then we may replace it with rte_flow, but I'm not sure if it's necessary, p= lease share if you have a better idea. BTW, are we going to move all other filter like mac , VLAN filter/strip/ins= ert into rte_flow finally? if that's the plan, though I don't have much inputs for this right now, but= I think we may not need to prevent new features be added based on current = API if it does not introduce more complexity and not break anything. >=20 >=20 >=20