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.