From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Wiles, Keith" Subject: Re: [PATCH v3 1/2] ethdev: add capability control API 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "Dumitrescu, Cristian" , Stephen Hemminger , DPDK , "jerin.jacob@caviumnetworks.com" , "balasubramanian.manoharan@cavium.com" , "hemant.agrawal@nxp.com" , "shreyansh.jain@nxp.com" , "Richardson, Bruce" To: Thomas Monjalon 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) In-Reply-To: <6779658.J26ZzuZ3zA@xps13> Content-Language: en-US Content-ID: <64273BF6754D48489F99EAEE0D1839DD@intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > 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