Re: [dpdk-dev] [RFC PATCH v2 3/5] librte_ether: add API's for VF management

[Thomas Monjalon <thomas.monjalon@6wind.com>]

2016-09-28 11:23, Ananyev, Konstantin:
> If we  this way (force user to include driver specific headers and call driver specific functions),
> how you guys plan to make this functionality available for multiple driver types.

Multiple drivers won't have exactly the same specific features.
But yes, there are some things common to several Intel NICs.

> From discussion with Bernard  understand that customers would need similar functionality for i40e.
> Does it mean that they'll have to re-implement this part of their code again?
> Or would have to create (and maintain) their own shim layer that would provide some s of abstraction?
> Basically their own version of rte_ethdev?

No definitive answer.
But we can argue the contrary: how to handle a generic API which is implemented
only in 1 or 2 drivers? If the application tries to use it, we can imagine
that a specific range of hardware is expected.

I think it is an important question.
Previously we had the issue of having some API which are too specific
and need a rework to be used with other NICs. In order to avoid such
rework and API break, we can try to make them available in a driver-specific
or vendor-specific staging area, waiting for a later generalization.