On 10/15/2019 3:16 PM, Jerin Jacob wrote: >>>>> @@ -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. >
+1 to not add deprecated features to the matrix, but those removed ones [1] are not deprecated. Implementing them via "filter_ctrl" is deprecated. Below features still can be implemented via "Flow API", that is why I am for adding them back to default.ini. And announce them as supported per PMD only if they are implemented via Flow API. [1] Ethertype filter = N-tuple filter = SYN filter = Tunnel filter = Flexible filter = Hash filter = Flow director =
