> -----Original Message-----
> From: Thomas Monjalon <tho...@monjalon.net>
> Sent: Thursday, January 7, 2021 6:12 PM
> To: Guo, Jia <jia....@intel.com>
> Cc: Zhang, Qi Z <qi.z.zh...@intel.com>; Wu, Jingjing <jingjing...@intel.com>;
> Yang, Qiming <qiming.y...@intel.com>; Wang, Haiyue
> <haiyue.w...@intel.com>; dev@dpdk.org; Yigit, Ferruh
> <ferruh.yi...@intel.com>; andrew.rybche...@oktetlabs.ru; or...@nvidia.com;
> getel...@nvidia.com
> Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for
> ecpri
>
> 07/01/2021 10:32, Guo, Jia:
> > From: Thomas Monjalon <tho...@monjalon.net>
> > > 24/12/2020 07:59, Jeff Guo:
> > > > Add type of RTE_TUNNEL_TYPE_ECPRI into the enum of ethdev tunnel
> > > type.
> > > >
> > > > Signed-off-by: Jeff Guo <jia....@intel.com>
> > > > Reviewed-by: Qi Zhang <qi.z.zh...@intel.com>
> > > [...]
> > > > --- 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...
So I think it's not a good idea to replace the rte_eth_dev_udp_tunnel_port_add
with rte_flow config
and also there is no existing rte_flow_action can cover this requirement unless
we introduce some new one.
> You can match, encap, decap.
> There is even a new API to get tunnel infos after decap.
> What is missing?
>
>
> > > Sorry, it is a nack.
> > > BTW, it is probably breaking the ABI because of RTE_TUNNEL_TYPE_MAX.
Yes that may break the ABI but fortunately the checking-abi-compatibility tool
shows negative :) , thanks Ferruh' s guide.
https://github.com/ferruhy/dpdk/actions/runs/468859673
Thanks
Qi
> >
> > Oh, the ABI break should be a problem.
> >
> > > PS: please Cc ethdev maintainers for such patch, thanks.
> > > tip: use --cc-cmd devtools/get-maintainer.sh
> >
> > Thanks for your helpful tip.
>
>
