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 0E729A0524; Fri, 8 Jan 2021 11:36:24 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CBC0D140F14; Fri, 8 Jan 2021 11:36:24 +0100 (CET) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) by mails.dpdk.org (Postfix) with ESMTP id 39233140F03 for ; Fri, 8 Jan 2021 11:36:23 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 9DAB51B4A; Fri, 8 Jan 2021 05:36:21 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Fri, 08 Jan 2021 05:36:22 -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= 06V8m6nxfj85HCME7sfQZrEeL2oRS2Bl7gcB63nobRY=; b=CTPUZK8HB9rU/1dt SF0IwndpKYLkjBBb0oyOwNWgSOZY44JqK/TaY5Fu/toXDaWjU4qARtr2SYWRaYbB UxgfOeslR22pZvvIo09r7vQwTuwIsm/wsdi4+rGalJ00PC4opNEYZo7upgPx0q04 t3c7Sojqd+WkkDYOwZI2/w0Ln3ZqKyNvLpQhUkuLbe3J4K5GFYXw59GMgLvLi+DU pGrM8po2ip+89TDh/t/mz25c2Vt9TaMbrL8hXbWC49nEB8NexvcJbOWPnUA4hm4f kNpJ5GW646/CTfJYotRPrG81Os9ol+OX2TBao6fya/ZQ/Nh2okSezz8l0RLK9XtO TF1Rdw== 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=06V8m6nxfj85HCME7sfQZrEeL2oRS2Bl7gcB63nob RY=; b=ff/Q2t4nTEhmERqigs4SqGkBEC96EHkjgx74PdtwwcUah2Ogawvdsttft Af4HLVnbx6gtfRZmo9uJkO8icg3Aw3lNNBZsKSs7VABvBoTcn8aArh+6ek/Bz99w qHcD5F+mO0pElc0zI19z7F+/Jx33Ru+e/plegWE/S8lvJMRQIsTTtOix+3Iuyo/p OirbWzj0egaNo4/wocGWVgfuKP/wRTb32UuIafFc4MS3sykpm+dgYZlaI4ogO4Qu 8evt4wWqe1UJuaYKoaOOUNFTNRXvhYoGBiKYP6XlQ55nVGK4DZersHnHh5+AvcD5 jHj8JAA4IHBT5tIUR/lY6quLCznOQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdeggedgudejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepfeelheeiteettefgudekteeihfeitefgvdefhfdtvdeifefggfeh teeffeduueefnecuffhomhgrihhnpehivghtfhdrohhrghenucfkphepjeejrddufeegrd dvtdefrddukeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf rhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth 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 ADAA324005D; Fri, 8 Jan 2021 05:36:19 -0500 (EST) From: Thomas Monjalon To: Ferruh Yigit , "Zhang, Qi Z" , "Guo, Jia" , Andrew Rybchenko Cc: "Wu, Jingjing" , "Yang, Qiming" , "Wang, Haiyue" , "dev@dpdk.org" , "orika@nvidia.com" , "getelson@nvidia.com" Date: Fri, 08 Jan 2021 11:36:18 +0100 Message-ID: <1974177.35SpgSOlpP@thomas> In-Reply-To: <3eb1ed08-01fe-d7d1-4540-e09a67e3077c@oktetlabs.ru> References: <20201216085854.7842-1-jia.guo@intel.com> <29e83a3d-4c22-c200-ba03-7aae54a7e07b@intel.com> <3eb1ed08-01fe-d7d1-4540-e09a67e3077c@oktetlabs.ru> 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" 08/01/2021 10:29, Andrew Rybchenko: > On 1/8/21 11:57 AM, Ferruh Yigit wrote: > > On 1/8/2021 1:41 AM, Zhang, Qi Z wrote: > >> From: Thomas Monjalon > >>> 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. Of course we can specify the UDP port in rte_flow rule. Please check rte_flow_item_udp. That's a basic of rte_flow. > > Isn't this more a device configuration than filtering, not sure about > > using rte_flow for this. > > +1 A device configuration? No, setting an UDP port is a stack configuration. > >> BTW, are we going to move all other filter like mac , VLAN > >> filter/strip/insert into rte_flow finally? Yes I think it should be the direction. All of this can be achieved with rte_flow. > >> 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. If we continue updating old API, we are just forking ourself: having 2 APIs for the same feature is a non-sense. We must remove APIs which are superseded by rte_flow.