From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id F339B2B84 for ; Fri, 30 Sep 2016 11:21:33 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga105.fm.intel.com with ESMTP; 30 Sep 2016 02:21:33 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,271,1473145200"; d="scan'208";a="1064382040" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.220.71]) by fmsmga002.fm.intel.com with SMTP; 30 Sep 2016 02:21:30 -0700 Received: by (sSMTP sendmail emulation); Fri, 30 Sep 2016 10:21:29 +0025 Date: Fri, 30 Sep 2016 10:21:29 +0100 From: Bruce Richardson To: Thomas Monjalon Cc: "Ananyev, Konstantin" , "Iremonger, Bernard" , dev@dpdk.org, Jerin Jacob , "Shah, Rahul R" , "Lu, Wenzhuo" , azelezniak Message-ID: <20160930092129.GA67296@bricha3-MOBL3> References: <1471528125-26357-1-git-send-email-bernard.iremonger@intel.com> <1669516.nga02iHeRI@xps13> <2601191342CEEE43887BDE71AB9772583F0BC36C@irsmsx105.ger.corp.intel.com> <5655161.kOlSb9MaAr@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5655161.kOlSb9MaAr@xps13> Organization: Intel Research and =?iso-8859-1?Q?De=ACvel?= =?iso-8859-1?Q?opment?= Ireland Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] [RFC PATCH v2 3/5] librte_ether: add API's for VF management X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2016 09:21:34 -0000 On Wed, Sep 28, 2016 at 08:02:21PM +0200, Thomas Monjalon wrote: > 2016-09-28 16:52, Ananyev, Konstantin: > > > > > > > > 2016-09-28 14:30, Ananyev, Konstantin: > > > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > > > > 2016-09-28 13:26, Ananyev, Konstantin: > > > > > > From: Thomas Monjalon [mailto: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. > > > > > > > > > > > > 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. > > > > > > > > > > We prefer having well-defined functions instead of opaque ioctl-style encoding. > > > > > And it was not clear what is the benefit of ioctl. > > > > > Now I think I understand you would like to have a common ioctl service for features available on 2 drivers. Right? > > > > > > > > Yes. > > > > > > > > > Example (trying to read your mind): > > > > > rte_ethdev_ioctl(port_id, ); instead of > > > > > rte_pmd_ixgbe_vf_ping(port_id, vf_id); > > > > > rte_pmd_i40e_vf_ping(port_id, vf_id); Please confirm I understand > > > > > what you are thinking about. > > > > > > > > Yep, you read my mind correctly :) > > > > > > Both could coexist (if ioctl was accepted by community). > > > > True. > > > > > What about starting to implement the PMD functions and postpone ioctl to later with a dedicated thread? > > > > You mean something like: > > - 16.11: implement rte_pmd_ixgbe_vf_ping() > > - 17.02: > > a) implement rte_pmd_i40e_vf_ping() > > b) introduce ioctl PMD API > > c) make possible to vf_ping via ioctl API > > ? > > If so, then it sounds like reasonable approach to me. > > Though would be inserting to hear what other guys think. > > Yes. > I would just add that we have to start a discussion thread to decide > wether we'll add an ioctl call in 17.02 or not. I still don't like IOCTLs as an option, I still think that they are awkward to use and hinder code readability. Here is an addition suggestion to get people thinking. How about allowing a set of "vendor-specific" operations for each device. We could do this using Bernard's suggestion of adding a set of additional function pointers to the device struct. The reason for doing this is that it would allow us to group functionality into families of functionality, rather than having to things either fully generically or specifically to each NIC. If we look at the capabilities of most NICs, the other NICs which support similar functions are generally other NICs from the same vendor. We could therefore have ops common across ixgbe and i40e and other ops mlx4 and mlx5 drivers. Could such a scheme work? Would it be worth doing? /Bruce