Re: [dpdk-dev] [PATCH v2 1/7] ethdev: introduce sample action for rte flow

[Thomas Monjalon <thomas@monjalon.net>]

03/07/2020 17:08, Jerin Jacob:
> On Fri, Jul 3, 2020 at 8:25 PM Matan Azrad <matan@mellanox.com> wrote:
> > From: Jerin Jacob:
> > > When adding overlapping API(rte_eth_mirror_rule_set()) in the same
> > > library(ethdev).
> > > Please depreciate the old API.
> > > We should not have two separate paths for the same function in the same
> > > ethdev library. It is pain for app and driver developers.
> >
> > What are about all the other rte_flow parallel configuration APIs in ethdev:
> >  promiscuous_enable;
> > promiscuous_disable;
> > allmulticast_enable;
> > allmulticast_disable;
> > mac_addr_remove;
> > mac_addr_add;
> > mac_addr_set;
> > set_mc_addr_list;
> > vlan_filter_set;
> > vlan_tpid_set;
> > vlan_strip_queue_set;
> > vlan_offload_set;
> > vlan_pvid_set;
> > udp_tunnel_port_add;
> > udp_tunnel_port_del;
> > ...
> >
> > These APIs can be replaced easily by rte_flow API.
> > Do you think we need to deprecate all?
> 
> I think, basic stuff like below can have separate API.
> 1)  promiscuous_enable;
> 2) promiscuous_disable;
> 3) allmulticast_enable;
> 4) allmulticast_disable;
> 5) mac_addr_remove;
> 6) mac_addr_add;
> 7) mac_addr_set;
> 8) set_mc_addr_list;

"Basic" is not a precise definition :)
I would say port-level configuration should remain
out of rte_flow API.

> But The VLAN and UDP related should be rte_flow candidates.(IMO)

Yes definitely, tunneling is better managed with rte_flow.

This is an important discussion, I Cc other ethdev maintainers.
Note: this is an ethdev patch, all ethdev maintainers should be Cc'ed.
Aren't you using --cc-cmd devtools/get-maintainer.sh ?