> >>> @@ -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. I agree. I think, we need to enumerate rte flow patterns and actions supported by the PMD. Since there was no single place such documentation, we added the same in PMD documentation See 39.8. RTE Flow Support at https://doc.dpdk.org/guides/nics/octeontx2.html And IMO, We should not add deprecated features in the features matrix as new PMDs are not planning to implement the deprecated APIs. That makes, matrix looks new PMDs do not implement a lot of features, but in reality, those are deprecated and never planning to implement if even though HW supports it.
