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

Thomas Monjalon thomas at monjalon.net
Fri Jul 7 16:02:22 CEST 2017


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.


More information about the dev mailing list