On 7/30/2019 4:57 PM, Thomas Monjalon wrote: > As legacy filter API "filter_ctrl" is superseded since 2017 > by the rte_flow API, and got the deprecated attribute in DPDK 19.05, > it is time to remove the associated features from the matrix. > Not documenting deprecated features as supported will avoid confusion. > > Signed-off-by: Thomas Monjalon <tho...@monjalon.net>
<...> > diff --git a/doc/guides/nics/features/default.ini > b/doc/guides/nics/features/default.ini > index f1a39d0f0..dfbdf084e 100644 > --- a/doc/guides/nics/features/default.ini > +++ b/doc/guides/nics/features/default.ini > @@ -36,13 +36,6 @@ VMDq = > SR-IOV = > DCB = > VLAN filter = > -Ethertype filter = > -N-tuple filter = > -SYN filter = > -Tunnel filter = > -Flexible filter = > -Hash filter = > -Flow director = > Flow control = > Flow API = > Rate limitation = I suggest adding these features back! "Flow director" and other filters are features that device/driver supports. And "Flow API" and "filter_ctrl" are methods used to implement these features. Indeed they are only different APIs to get input from application/user. It doesn't really mean much to say "Flow API" is supported? So what is really supported? It matters more what feature is supported. Since we are saying old method is deprecated, we can update the feature list of drivers which implements filtering features using old method as not supported. And that is the case with this patch since old APIs are marked as deprecated, users can't use them to enable a filtering feature. Indeed I am for removing the "Flow API" from feature list, first it is not a feature, second if it is only method to enable a filtering, and if filtering is enabled in a driver, what is the point of redundant "Flow API" listing? I can make a quick patch if there is no objection, thanks.
