[dpdk-dev] [PATCH] cryptodev: mark experimental state

Doherty, Declan declan.doherty at intel.com
Thu Nov 26 14:51:16 CET 2015


> -----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.



More information about the dev mailing list