[dpdk-dev] [PATCH v3] doc: document NIC features

[Ferruh Yigit]

On 7/7/2017 3:02 PM, Thomas Monjalon wrote:
> 07/07/2017 15:57, Ferruh Yigit:
>> On 7/7/2017 2:53 PM, Thomas Monjalon wrote:
>>> 07/07/2017 15:37, Ferruh Yigit:
>>>> On 7/7/2017 11:55 AM, Andrew Rybchenko wrote:
>>>>> Also some PMDs have few implementations of the datapath (like vector and 
>>>>> usual). Ideally
>>>>> we need common way to highlight it. May be it is OK that control path 
>>>>> features are duplicated
>>>>> in this case, but ideally it should be expressed somehow.
>>>>
>>>> I agree different datapath implementations can be documented better, I
>>>> just don't know how to do ...
>>>>
>>>> For some drivers there are multiple vector implementations and the
>>>> feature set for them is not clear. And as you said control features are
>>>> duplicated in the table.
>>>>
>>>> Perhaps control and datapath features can be separated.
>>>>
>>>> Or as Thomas suggested sometime ago, vector and scalar version can be
>>>> merged into one in the table and feature can be marked as supported if
>>>> both scalar and vector has support for it. But this is not solving
>>>> multiple vector implementation problem.
>>>
>>> Yes it is the way to go.
>>> The features should not be different from a datapath implementation to
>>> another one. So they must be merged in only one column.
>>> If a feature is not supported in every datapaths of a driver, it should
>>> be marked as partially supported... and the developers must implement it.
>>
>> But for example for i40e, there are altivec, neon and sse vector
>> implementations, how should we document this?
> 
> They are all only one i40 driver. It should offer the same features
> regardless of the platform it runs on.
> So it should be only one column in the table.

If one platform does not implements a feature, it will cause feature
will be documented as partial independent from other platform's status,
this is unfair for the ones implemented it.