07/07/2017 16:20, Wiles, Keith: > > > On Jul 7, 2017, at 9:13 AM, Ferruh Yigit <ferruh.yi...@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. 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.
