On 10/15/2019 1:31 PM, Andrew Rybchenko wrote: > Cc Adrien > > On 10/15/19 2:08 PM, Yigit, Ferruh wrote: >> 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. > > As I understand it was a decision to avoid details about flow API support > in features matrix. Mainly because matrix would be really huge in > attempt to represent it. The question is why filters/patterns mentioned > above are better than others and should be mentioned. > I'm not against adding some details, just want to understand criteria. > Flexible and hash are definitely not well defined. > What is flow director and which features should be supported to say yes? >
The criteria I have is what users will be interested about a device/driver. Will it be really huge to list filtering capabilities of the devices? I believe we can group them into a few groups like above. Or at least keep existing one and improve it by time and +1 to clarify them more but that is something else. A device can have capabilities but it is not easy to find if that capability has been enabled via DPDK, this kind of feature matrix works for it, and all features together makes it much easier than digging datasheets and code. Saying that "Flow API" is enabled for a driver doesn't really gives any information to the user if they are interested what kind of filtering features are supported by that device/driver.
