[dpdk-dev] [PATCH] doc: remove deprecated ethdev features

[Andrew Rybchenko]

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 <thomas at 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?