On 10/25/2019 2:39 PM, Jerin Jacob wrote: > On Fri, Oct 25, 2019 at 6:56 PM Thomas Monjalon <[email protected]> wrote: >> >> 25/10/2019 14:51, Ferruh Yigit: >>> "Flow API" is a method/API to implement various filtering features, on >>> its own it doesn't give much context on what features are provided. And >>> it is not really a feature, so doesn't fit into feature table. >>> >>> Also since other filtering related APIs, 'filter_ctrl', has been >>> deprecated, flow API is the only supported way in the DPDK to implement >>> filtering options, if related filter options announced by PMDs, listing >>> "Flow API" as implemented is redundant information. >> >> I fully agree with this explanation. >> rte_flow is the only supported API for flow offloads. >> That's why we must remove the legacy API. >> >>> Signed-off-by: Ferruh Yigit <[email protected]> >>> --- >>> --- a/doc/guides/nics/features/default.ini >>> +++ b/doc/guides/nics/features/default.ini >>> -Flow API = >> >> Acked-by: Thomas Monjalon <[email protected]> > > # Need to remove "Flow API" from doc/guides/nics/features.rst
+1 > # Need to remove refference of "Flow API" from "doc/guides/nics/*" as well. "Flow API" is the implementation of the filtering, it may exist in the nic documentation, only it is not a feature on itself. I will scan the docs for usage. > > Not specific to this patch, > Probably we need to add a new matrix to enumerate PATTERN and ACTIONS > supported by each PMD as a rte_flow feature matrix. > That some else can take it up if everyone agrees the semantics. > +1, there needs a way to figure out which filtering is supported by a device/driver. It is not documented and it is very hard to got it from the code. Not sure if a new matrix is the good way to go, but I agree we need some way to clarify it.
