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

[Wiles, Keith]

> On Mar 7, 2017, at 6:56 AM, Thomas Monjalon <thomas.monjalon at 6wind.com> wrote:
> 
> 2017-03-07 10:14, Dumitrescu, Cristian:
>> From: Stephen Hemminger [mailto:stephen at networkplumber.org]
>>> On Mon, 6 Mar 2017 20:41:27 +0000
>>> "Wiles, Keith" <keith.wiles at 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.

One simple solution is to create inline function with the correct prototypes and a reasonable name for that function. The inline will just call the generic API providing the enum and the structure pointer converted into a void *. Using this simple method we get both solutions and adding a strong type check.

Regards,
Keith