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.
