Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri
From: Andrew Rybchenko <hidden>
Date: 2021-01-07 10:09:55
On 1/7/21 12:32 PM, Guo, Jia wrote:
quoted
-----Original Message----- From: Thomas Monjalon <redacted> Sent: Thursday, January 7, 2021 6:12 AM To: Guo, Jia <redacted> Cc: Zhang, Qi Z <redacted>; Wu, Jingjing [off-list ref]; Yang, Qiming [off-list ref]; Wang, Haiyue [off-list ref]; dev@dpdk.org; Yigit, Ferruh [off-list ref]; andrew.rybchenko@oktetlabs.ru Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri 24/12/2020 07:59, Jeff Guo:quoted
Add type of RTE_TUNNEL_TYPE_ECPRI into the enum of ethdev tunneltype.quoted
Signed-off-by: Jeff Guo <redacted> Reviewed-by: Qi Zhang <redacted>[...]quoted
--- 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.
Which legacy API is kept? (I've tried to cleanup drivers, but it is not always easy to do and I relied on driver maintainers) If you are talking about an API to set UDP port for UDP-based tunnels, yes it is kept right now since there is no replacement yet. It looks like eCRPI could be encapsulated in UDP, but I don't know if UDP port is fixed for the tunnel type or requires configuring.