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

[Ananyev, Konstantin]

> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Wednesday, September 28, 2016 2:03 PM
> To: Ananyev, Konstantin <konstantin.ananyev at intel.com>
> Cc: Iremonger, Bernard <bernard.iremonger at intel.com>; Richardson, Bruce <bruce.richardson at intel.com>; dev at dpdk.org; Jerin
> Jacob <jerin.jacob at caviumnetworks.com>; Shah, Rahul R <rahul.r.shah at intel.com>; Lu, Wenzhuo <wenzhuo.lu at intel.com>;
> azelezniak <alexz at att.com>
> Subject: Re: [dpdk-dev] [RFC PATCH v2 3/5] librte_ether: add API's for VF management
> 
> 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.

Yes, as I understand, it is a specific subset of supported HW (just Inel NICs for now, but different models/drivers).
Obviously users would like to have an ability to run their app on all HW from this subset without rebuilding/implementing the app.

> 
> 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.

Could you remind me why you guys were that opposed to ioctl style approach?
It is not my favorite thing either, but it seems pretty generic way to handle such situations.

Konstantin