From: "Doherty, Declan" <declan.doherty@intel.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>,
Panu Matilainen <pmatilai@redhat.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] cryptodev: mark experimental state
Date: Thu, 26 Nov 2015 13:51:16 +0000 [thread overview]
Message-ID: <345C63BAECC1AD42A2EC8C63AFFC3ADC2809A787@irsmsx105.ger.corp.intel.com> (raw)
In-Reply-To: <34498752.nGP1cUxCqE@xps13>
> -----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=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.
next prev parent reply other threads:[~2015-11-26 13:51 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-25 17:38 Thomas Monjalon
2015-11-25 20:59 ` Thomas Monjalon
2015-11-26 7:39 ` Panu Matilainen
2015-11-26 8:00 ` Panu Matilainen
2015-11-26 10:08 ` Thomas Monjalon
2015-11-26 13:51 ` Doherty, Declan [this message]
2015-11-27 13:09 ` Panu Matilainen
2015-11-27 13:30 ` Thomas Monjalon
2015-12-11 23:34 ` [dpdk-dev] [PATCH] mbuf_offload: " Thomas Monjalon
2015-12-11 23:44 ` Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=345C63BAECC1AD42A2EC8C63AFFC3ADC2809A787@irsmsx105.ger.corp.intel.com \
--to=declan.doherty@intel.com \
--cc=dev@dpdk.org \
--cc=pmatilai@redhat.com \
--cc=thomas.monjalon@6wind.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).