[dpdk-dev] dev Digest, Vol 68, Issue 68

[Betts, Ian]

Date: Fri, 27 Nov 2015 15:09:24 +0200
From: Panu Matilainen <pmatilai at redhat.com>
To: "Doherty, Declan" <declan.doherty at intel.com>, Thomas Monjalon
	<thomas.monjalon at 6wind.com>
Cc: "dev at dpdk.org" <dev at dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] cryptodev: mark experimental state
Message-ID: <56585604.9030909 at redhat.com>
Content-Type: text/plain; charset=utf-8; format=flowed

On 11/26/2015 03:51 PM, Doherty, Declan wrote:
>> -----Original Message-----
>> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
>> Sent: Thursday, November 26, 2015 10:09 AM
>> To: Panu Matilainen; Doherty, Declan
>> Cc: dev at 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=y
>>>>>
>>>>>    #
>>>>>    # Compile generic crypto device library
>>>>> +# EXPERIMENTAL: API may change without prior notice
>>>>>    #
>>>>>    CONFIG_RTE_LIBRTE_CRYPTODEV=y
>>>>>    CONFIG_RTE_LIBRTE_CRYPTODEV_DEBUG=n
>>>> [...]
>>>>
>>>> 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, it'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 default, 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 the
> fewer build configurations developers have to test against the better.

>>What I'm more worried about is users and developers starting to rely on 
>>it while still in experimental state, a single comment in the header is 
>>really easy to miss.

>>So I'd like to see *some* mechanism which forces users and developers to 
>>acknowledge the fact that they're dealing with experimental work. 
>>Defaulting to off is one possibility, another one would be wrapping 
>>experimental APIs behind a define which you have to set to be able to 
>>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 "experimental" patch state in patchwork. 


This approach might be useful to get wider exposure and feedback on  experimental work earlier in its lifecycle.
Experimental patches may be constrained to a limited subset of target and host environments.
Experimental patches should be based off of a stable dpdk release, but would not be applied in the release.

Whilst the objective would be that any such patch would mature to  become the kind of "experimental component" 
as proposed above in this thread, and/or eventually be adopted as a mainstream component, 
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. 

The only reason to have a new patchwork state is to make it easier to filter them in patchwork.
Some way of publishing the list of experimental patches available for a release would be
helpful, maybe as an addendum to the release note ?