Re: [PATCH v3 1/2] ethdev: add capability control API

[Thomas Monjalon <thomas.monjalon@6wind.com>]

2017-03-07 10:14, Dumitrescu, Cristian:
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > On Mon, 6 Mar 2017 20:41:27 +0000
> > "Wiles, Keith" <keith.wiles@intel.com> wrote:
> > 
> > > Being able to add features without having to change DPDK maybe a strong
> > feature for companies that have special needs for its application. They just
> > need to add a rte_eth_capability enum in a range that they want to control
> > (which does not mean they need to change the above structure) and they
> > can provide private features to the application especially if they are very
> > specific features to some HW. I do not like private features, but I also do not
> > want to stick just any old API in DPDK for any given special feature.
> > 
> > 
> > I understand why you make that argument, but in practice it doesn't work
> > that way.
> > When new features get added to DPDK, then the application must request
> > those features through configration and other
> > API's. Therefore building everything into eth_dev doesn't seem to be
> > helpful.
> 
> Stephen, I think we are all aligned here. Question is: do you want the application to discover the supported capabilities through a standard API or do you want each capability to provide its own specific discovery mechanism (if any)? This patch proposes a standard API.

Just a precision: A function with a void* parameter is not a fully defined API.
We still need to know how to interpret the void* in each case.