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 8B20DA0524; Fri, 8 Jan 2021 09:58:07 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4B7A8140E95; Fri, 8 Jan 2021 09:58:07 +0100 (CET) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by mails.dpdk.org (Postfix) with ESMTP id D235B140D64 for ; Fri, 8 Jan 2021 09:58:05 +0100 (CET) IronPort-SDR: E6jfkY10OjPQ8Spmqj7xYvfl3DYKvbLZT+ttJYQcMU+8ZsFUE5ydo2Qbavj++nVy9klCCNVZQo 347kwnuIjfZg== X-IronPort-AV: E=McAfee;i="6000,8403,9857"; a="157345726" X-IronPort-AV: E=Sophos;i="5.79,330,1602572400"; d="scan'208";a="157345726" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jan 2021 00:58:03 -0800 IronPort-SDR: 6JjfnT19Tz9xJShYpis2+wt9DRL91xGmbNrHDbAzIkqlMEgH28LbliPGW40bxPiYMNPKMWvaNy Dg7waPBjZMKQ== X-IronPort-AV: E=Sophos;i="5.79,330,1602572400"; d="scan'208";a="398924876" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.237.192]) ([10.213.237.192]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jan 2021 00:58:00 -0800 To: "Zhang, Qi Z" , Thomas Monjalon , "Guo, Jia" Cc: "Wu, Jingjing" , "Yang, Qiming" , "Wang, Haiyue" , "dev@dpdk.org" , "andrew.rybchenko@oktetlabs.ru" , "orika@nvidia.com" , "getelson@nvidia.com" , Dodji Seketeli References: <20201216085854.7842-1-jia.guo@intel.com> <27289607.Vi9ZVq1Shk@thomas> <87efb4f6a3554bf4b2bba5a495efccb0@intel.com> <2049408.mdQoWhQ2pd@thomas> <3979f8a247474b64a9c7f6fcd84b9c4f@intel.com> From: Ferruh Yigit Message-ID: <29e83a3d-4c22-c200-ba03-7aae54a7e07b@intel.com> Date: Fri, 8 Jan 2021 08:57:57 +0000 MIME-Version: 1.0 In-Reply-To: <3979f8a247474b64a9c7f6fcd84b9c4f@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit 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" On 1/8/2021 1:41 AM, Zhang, Qi Z wrote: > > >> -----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 >> >> 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? > > I think if we have a rte_flow action type that can be used to set a packet's tunnel type xxx, like below > #flow create eth/ipv4/udp port is 4789/... action set_tunnel_type VxLAN / end > then we may replace it with rte_flow, but I'm not sure if it's necessary, please share if you have a better idea. > Isn't this more a device configuration than filtering, not sure about using rte_flow for this. > BTW, are we going to move all other filter like mac , VLAN filter/strip/insert 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. > > >> >> >> >