> -----Original Message----- > From: Stephen Hemminger [mailto:step...@networkplumber.org] > Sent: Monday, March 6, 2017 8:54 PM > To: Wiles, Keith <keith.wi...@intel.com> > Cc: Thomas Monjalon <thomas.monja...@6wind.com>; Dumitrescu, Cristian > <cristian.dumitre...@intel.com>; DPDK <dev@dpdk.org>; > jerin.ja...@caviumnetworks.com; > balasubramanian.manoha...@cavium.com; hemant.agra...@nxp.com; > shreyansh.j...@nxp.com; Richardson, Bruce <bruce.richard...@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.wi...@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.
