> -----Original Message----- > From: Stephen Hemminger [mailto:[email protected]] > Sent: Monday, March 6, 2017 8:54 PM > To: Wiles, Keith <[email protected]> > Cc: Thomas Monjalon <[email protected]>; Dumitrescu, Cristian > <[email protected]>; DPDK <[email protected]>; > [email protected]; > [email protected]; [email protected]; > [email protected]; Richardson, Bruce <[email protected]> > Subject: Re: [dpdk-dev] [PATCH v3 1/2] ethdev: add capability control API > > On Mon, 6 Mar 2017 20:41:27 +0000 > "Wiles, Keith" <[email protected]> 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.
