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

["Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>]

> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Monday, March 6, 2017 8:54 PM
> To: Wiles, Keith <keith.wiles@intel.com>
> Cc: Thomas Monjalon <thomas.monjalon@6wind.com>; Dumitrescu, Cristian
> <cristian.dumitrescu@intel.com>; DPDK <dev@dpdk.org>;
> jerin.jacob@caviumnetworks.com;
> balasubramanian.manoharan@cavium.com; hemant.agrawal@nxp.com;
> shreyansh.jain@nxp.com; Richardson, Bruce <bruce.richardson@intel.com>
> Subject: Re: [dpdk-dev] [PATCH v3 1/2] ethdev: add capability control API
> 
> 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.