From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 59DA0569C for ; Wed, 9 Dec 2015 11:40:26 +0100 (CET) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga103.jf.intel.com with ESMTP; 09 Dec 2015 02:40:25 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,403,1444719600"; d="scan'208";a="857150784" Received: from irsmsx106.ger.corp.intel.com ([163.33.3.31]) by fmsmga001.fm.intel.com with ESMTP; 09 Dec 2015 02:40:25 -0800 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.13]) by IRSMSX106.ger.corp.intel.com ([169.254.8.228]) with mapi id 14.03.0248.002; Wed, 9 Dec 2015 10:40:23 +0000 From: "Betts, Ian" To: "dev@dpdk.org" Thread-Topic: dev Digest, Vol 68, Issue 68 Thread-Index: AQHRKRiFuBIt6nFcNUuE+EUDX1Hh+p7Cgsog Date: Wed, 9 Dec 2015 10:40:22 +0000 Message-ID: <877C1F8553E92F43898365570816082F35C0C84D@IRSMSX103.ger.corp.intel.com> References: In-Reply-To: Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-inteldataclassification: CTP_IC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsIiwiaWQiOiI1YzIwMzViZS04ZjE3LTQ4OTQtYTk5My0xMzUyZjhiZGVlOGMiLCJwcm9wcyI6W3sibiI6IkludGVsRGF0YUNsYXNzaWZpY2F0aW9uIiwidmFscyI6W3sidmFsdWUiOiJDVFBfSUMifV19XX0sIlN1YmplY3RMYWJlbHMiOltdLCJUTUNWZXJzaW9uIjoiMTUuNC4xMC4xOSIsIlRydXN0ZWRMYWJlbEhhc2giOiJpbmNkeHdvY0JsUVU5R1Mza1d3bWJ0Wmg1VUVcLzNDaEZPNTI1XC82R2xzWFE9In0= x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] dev Digest, Vol 68, Issue 68 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: Wed, 09 Dec 2015 10:40:26 -0000 Date: Fri, 27 Nov 2015 15:09:24 +0200 From: Panu Matilainen To: "Doherty, Declan" , Thomas Monjalon Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH] cryptodev: mark experimental state Message-ID: <56585604.9030909@redhat.com> Content-Type: text/plain; charset=3Dutf-8; format=3Dflowed On 11/26/2015 03:51 PM, Doherty, Declan wrote: >> -----Original Message----- >> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] >> Sent: Thursday, November 26, 2015 10:09 AM >> To: Panu Matilainen; Doherty, Declan >> Cc: dev@dpdk.org >> Subject: Re: [dpdk-dev] [PATCH] cryptodev: mark experimental state >> >> 2015-11-26 10:00, Panu Matilainen: >>> On 11/26/2015 09:39 AM, Panu Matilainen wrote: >>>> On 11/25/2015 07:38 PM, Thomas Monjalon wrote: >>>>> --- a/config/common_linuxapp >>>>> +++ b/config/common_linuxapp >>>>> @@ -319,6 +319,7 @@ CONFIG_RTE_PMD_PACKET_PREFETCH=3Dy >>>>> >>>>> # >>>>> # Compile generic crypto device library >>>>> +# EXPERIMENTAL: API may change without prior notice >>>>> # >>>>> CONFIG_RTE_LIBRTE_CRYPTODEV=3Dy >>>>> CONFIG_RTE_LIBRTE_CRYPTODEV_DEBUG=3Dn >>>> [...] >>>> >>>> I think an experimental library which declares itself exempt from the >>>> ABI policy should not be compiled by default. That way anybody wanting >>>> to try it out will be forced to notice the experimental status. >>>> >>>> More generally / longer term, perhaps there should be a >>>> CONFIG_RTE_EXPERIMENTAL which wraps all experimental features and >>>> defaults to off. >>> >>> On a related note, librte_mbuf_offload cannot be built if >>> CONFIG_RTE_LIBRTE_CRYPTODEV is disabled. Which seems to suggest its (at >>> least currently) so tightly couple to cryptodev that perhaps it too >>> should be marked experimental and default to off. >> >> I think you are right. >> Declan, what is your opinion? > > > Hey Thomas, yes librte_mbuf_offload should also be set as experimental, i= t's > probably one of the areas which will most likely change in the future. > > On the issue of turning off experimental libraries in the build by defaul= t, my > preference would be not to turn them off unless the library has external > dependencies, otherwise the possibility of patches being submitted which > could break an experimental library will be much higher. In my opinion th= e > fewer build configurations developers have to test against the better. >>What I'm more worried about is users and developers starting to rely on=20 >>it while still in experimental state, a single comment in the header is=20 >>really easy to miss. >>So I'd like to see *some* mechanism which forces users and developers to= =20 >>acknowledge the fact that they're dealing with experimental work.=20 >>Defaulting to off is one possibility, another one would be wrapping=20 >>experimental APIs behind a define which you have to set to be able to=20 >>use the API, eg: >>#if defined(I_KNOW_THIS_IS_EXPERIMENTAL_AND_MAY_EAT_BABIES) >>[...] >>#endif >> - Panu - I can see alternative/complementary that is to introduce a new "experiment= al" patch state in patchwork.=20 This approach might be useful to get wider exposure and feedback on experi= mental work earlier in its lifecycle. Experimental patches may be constrained to a limited subset of target and h= ost environments. Experimental patches should be based off of a stable dpdk release, but woul= d not be applied in the release. Whilst the objective would be that any such patch would mature to become t= he kind of "experimental component"=20 as proposed above in this thread, and/or eventually be adopted as a mainstr= eam component,=20 there would be no guarantee of that. For the user it should very clearly be "Buyer beware" on such patches, and= for the developer community the support burden should be solely the responsibility= of the patch maintainer.=20 The only reason to have a new patchwork state is to make it easier to filte= r them in patchwork. Some way of publishing the list of experimental patches available for a rel= ease would be helpful, maybe as an addendum to the release note ?