From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id B2C821BBE for ; Tue, 7 Mar 2017 20:17:07 +0100 (CET) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga104.jf.intel.com with ESMTP; 07 Mar 2017 11:17:06 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,258,1486454400"; d="scan'208";a="65201307" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by orsmga004.jf.intel.com with ESMTP; 07 Mar 2017 11:17:06 -0800 Received: from fmsmsx112.amr.corp.intel.com (10.18.116.6) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 7 Mar 2017 11:17:06 -0800 Received: from fmsmsx113.amr.corp.intel.com ([169.254.13.172]) by FMSMSX112.amr.corp.intel.com ([169.254.5.137]) with mapi id 14.03.0248.002; Tue, 7 Mar 2017 11:17:05 -0800 From: "Wiles, Keith" To: Thomas Monjalon CC: "Dumitrescu, Cristian" , Stephen Hemminger , DPDK , "jerin.jacob@caviumnetworks.com" , "balasubramanian.manoharan@cavium.com" , "hemant.agrawal@nxp.com" , "shreyansh.jain@nxp.com" , "Richardson, Bruce" Thread-Topic: [dpdk-dev] [PATCH v3 1/2] ethdev: add capability control API Thread-Index: AQHSlpeqbOHz0w9xmUeucMjNJegaXqGIjlaAgAAZYgCAAB+zgIAABY+AgAADoICAAN9+AIAALWwAgABqNoA= Date: Tue, 7 Mar 2017 19:17:05 +0000 Message-ID: <25339BB4-4B91-448E-871C-1EC3C76857BD@intel.com> References: <1488589820-206947-1-git-send-email-cristian.dumitrescu@intel.com> <20170306125425.51b6455b@xeon-e3> <3EB4FA525960D640B5BDFFD6A3D891265275B5BA@IRSMSX108.ger.corp.intel.com> <6779658.J26ZzuZ3zA@xps13> In-Reply-To: <6779658.J26ZzuZ3zA@xps13> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.71.106] Content-Type: text/plain; charset="us-ascii" Content-ID: <64273BF6754D48489F99EAEE0D1839DD@intel.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v3 1/2] ethdev: add capability control API X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 19:17:08 -0000 > On Mar 7, 2017, at 6:56 AM, Thomas Monjalon w= rote: >=20 > 2017-03-07 10:14, Dumitrescu, Cristian: >> From: Stephen Hemminger [mailto:stephen@networkplumber.org] >>> On Mon, 6 Mar 2017 20:41:27 +0000 >>> "Wiles, Keith" wrote: >>>=20 >>>> Being able to add features without having to change DPDK maybe a stron= g >>> feature for companies that have special needs for its application. They= just >>> need to add a rte_eth_capability enum in a range that they want to cont= rol >>> (which does not mean they need to change the above structure) and they >>> can provide private features to the application especially if they are = very >>> specific features to some HW. I do not like private features, but I als= o do not >>> want to stick just any old API in DPDK for any given special feature. >>>=20 >>>=20 >>> I understand why you make that argument, but in practice it doesn't wor= k >>> that way. >>> When new features get added to DPDK, then the application must request >>> those features through configration and other >>> API's. Therefore building everything into eth_dev doesn't seem to be >>> helpful. >>=20 >> Stephen, I think we are all aligned here. Question is: do you want the a= pplication to discover the supported capabilities through a standard API or= do you want each capability to provide its own specific discovery mechanis= m (if any)? This patch proposes a standard API. >=20 > Just a precision: A function with a void* parameter is not a fully define= d API. > We still need to know how to interpret the void* in each case. One simple solution is to create inline function with the correct prototype= s and a reasonable name for that function. The inline will just call the ge= neric API providing the enum and the structure pointer converted into a voi= d *. Using this simple method we get both solutions and adding a strong typ= e check. Regards, Keith