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

["Zhang, Qi Z" <qi.z.zhang@intel.com>]

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

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.


> 
> 
>