[dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri

[Andrew Rybchenko]

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 <thomas at monjalon.net>
>>> Sent: Friday, January 8, 2021 12:59 AM
>>> To: Guo, Jia <jia.guo at intel.com>; Zhang, Qi Z <qi.z.zhang at intel.com>
>>> Cc: Wu, Jingjing <jingjing.wu at intel.com>; Yang, Qiming
>>> <qiming.yang at intel.com>; Wang, Haiyue <haiyue.wang at intel.com>;
>>> dev at dpdk.org; Yigit, Ferruh <ferruh.yigit at intel.com>;
>>> andrew.rybchenko at oktetlabs.ru; orika at nvidia.com; getelson at nvidia.com;
>>> Dodji Seketeli <dodji at redhat.com>
>>> 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 <thomas at monjalon.net>
>>>>> 07/01/2021 13:47, Zhang, Qi Z:
>>>>>> From: Thomas Monjalon <thomas at monjalon.net>
>>>>>>> 07/01/2021 10:32, Guo, Jia:
>>>>>>>> From: Thomas Monjalon <thomas at monjalon.net>
>>>>>>>>> 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.