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 48962A0524; Fri, 8 Jan 2021 10:29:42 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CB3D4140D1A; Fri, 8 Jan 2021 10:29:41 +0100 (CET) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id CC9B5140CD9 for ; Fri, 8 Jan 2021 10:29:40 +0100 (CET) Received: from [192.168.1.71] (unknown [188.170.80.211]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id E91DD7F523; Fri, 8 Jan 2021 12:29:39 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru E91DD7F523 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1610098180; bh=KJ1CwFs4kha1b9v7TR5Q6UDGoRU2n1VUTY7hy6uX1+Q=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=nc+jSopL7jMXvRobxPi3YzvZnUj15ajuB+6VAQ/O0aH7gdNg1am7gV86cru9P4i/K hOOUG1w8tq7bghsR+2lk6Usn7L/mDAYF4Y5HkCSEui8R/jnvb/ZyBZkjbWC7+2Inqf C9n4MqeqkOw3EnFCHk4a4JuBWiUVkB5U4fs9x+Bc= To: Ferruh Yigit , "Zhang, Qi Z" , Thomas Monjalon , "Guo, Jia" Cc: "Wu, Jingjing" , "Yang, Qiming" , "Wang, Haiyue" , "dev@dpdk.org" , "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> <29e83a3d-4c22-c200-ba03-7aae54a7e07b@intel.com> From: Andrew Rybchenko Message-ID: <3eb1ed08-01fe-d7d1-4540-e09a67e3077c@oktetlabs.ru> Date: Fri, 8 Jan 2021 12:29:32 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <29e83a3d-4c22-c200-ba03-7aae54a7e07b@intel.com> Content-Language: en-US Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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/21 11:57 AM, Ferruh Yigit wrote: > 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. +1 >> 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.