On Fri, Jul 3, 2020 at 8:57 PM Thomas Monjalon <tho...@monjalon.net> wrote: > > 03/07/2020 17:08, Jerin Jacob: > > On Fri, Jul 3, 2020 at 8:25 PM Matan Azrad <ma...@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 :)
Yep. > I would say port-level configuration should remain > out of rte_flow API. +1. In addition that, I would say anything needs to configured at "per-flow" granularity use rte_flow. > > > 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 ? > >
