-----Original Message-----
From: Stephen Hemminger [mailto:stephen@networkplumber.org]
Sent: Monday, March 6, 2017 8:54 PM
To: Wiles, Keith <redacted>
Cc: Thomas Monjalon <redacted>; Dumitrescu, Cristian
[off-list ref]; DPDK [off-list ref];
jerin.jacob@caviumnetworks.com;
balasubramanian.manoharan@cavium.com; hemant.agrawal@nxp.com;
shreyansh.jain@nxp.com; Richardson, Bruce [off-list ref]
Subject: Re: [dpdk-dev] [PATCH v3 1/2] ethdev: add capability control API

On Mon, 6 Mar 2017 20:41:27 +0000
"Wiles, Keith" [off-list ref] wrote:

quoted

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.