From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [RFC PATCH v2 3/5] librte_ether: add API's for VF management Date: Wed, 28 Sep 2016 15:03:18 +0200 Message-ID: <1918603.2PG7Ygo6cR@xps13> References: <1471528125-26357-1-git-send-email-bernard.iremonger@intel.com> <8CEF83825BEC744B83065625E567D7C21A08D86D@IRSMSX108.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772583F0BC0A3@irsmsx105.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: "Iremonger, Bernard" , "Richardson, Bruce" , dev@dpdk.org, Jerin Jacob , "Shah, Rahul R" , "Lu, Wenzhuo" , azelezniak To: "Ananyev, Konstantin" Return-path: Received: from mail-lf0-f54.google.com (mail-lf0-f54.google.com [209.85.215.54]) by dpdk.org (Postfix) with ESMTP id 95F622A58 for ; Wed, 28 Sep 2016 15:03:21 +0200 (CEST) Received: by mail-lf0-f54.google.com with SMTP id l131so51024529lfl.2 for ; Wed, 28 Sep 2016 06:03:21 -0700 (PDT) In-Reply-To: <2601191342CEEE43887BDE71AB9772583F0BC0A3@irsmsx105.ger.corp.intel.com> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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.