[dpdk-dev] [PATCH] doc: remove deprecated ethdev features
Ferruh Yigit
ferruh.yigit at intel.com
Tue Oct 15 17:55:53 CEST 2019
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 =
More information about the dev
mailing list