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

Thomas Monjalon thomas at monjalon.net
Fri Jul 7 22:37:06 CEST 2017


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


More information about the dev mailing list