Re: [PATCH v3] doc: document NIC features

["Wiles, Keith" <keith.wiles@intel.com>]

> On Jul 7, 2017, at 3:37 PM, Thomas Monjalon <thomas@monjalon.net> wrote:
> 
> 07/07/2017 16:20, Wiles, Keith:
>> 
>>> On Jul 7, 2017, at 9:13 AM, Ferruh Yigit <ferruh.yigit@intel.com> wrote:
>>> 
>>> 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.
>> 
>> +1
>> 
>> If a single PMD supports different platforms, then we need to be able to identify these NICs plus show the features.
>> Having multiple lines in a table is not difficult and helps identify exactly what is supported on all platforms.
> 
> No, you miss the point.
> I don't care about the table, it is just a tool to target uniform
> implementation. DPDK must be multi-platform. It means an application
> relying on a feature must work when changing the CPU.

I guess I am not following this point if you change a CPU from ARM to IA then I am sure a number of features stop working or the NIC can not build at all. I am sure that is not what you meant. If a NIC supports a feature, but may not support that feature in all CPU’s of the same family then ‘P’ seems reasonable, but it does not really help the developer without more details. 

I wrote a big reply here, but I figured I would trim down to this statement. We are trying to put 20 pounds(pick your favorite measurement) of ‘stuff’ in to a 5 pound bag :-)

I ‘really’ appreciate the effort it took to build this table plus it will be hard to keep current. The table may have to be broken into multiple tables or figure out how to add all of the possible CPU classes in each Arch ARM, IA, Power... A top table which helps the user move to the next table and then next table till he finds all of the right set of CPU Arch, Class and NIC features plus let’s not forget the OS type.

I agree the table is not your point, but the table does become the point when you start talking about what is supported in what Arch/Class/NIC/OS as the table is only 2D, maybe a 3D table :-) (like d3js.org)

> 
> If a PMD maintainer wants its features advertised as fully supported,
> he must reject partial datapath implementation.
> It is fair because it is the maintainer's choice.


Regards,
Keith