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

[Ferruh Yigit]

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.

> 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.
> 
> 
>>
>>
>>
>