2017-03-07 10:14, Dumitrescu, Cristian: > From: Stephen Hemminger [mailto:step...@networkplumber.org] > > 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.
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.
