Message ID | 1459842793-18071-1-git-send-email-fiona.trahe@intel.com (mailing list archive) |
---|---|
State | Superseded, archived |
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [IPv6:::1]) by dpdk.org (Postfix) with ESMTP id 2B3C52BF8; Tue, 5 Apr 2016 10:02:37 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 626AE952 for <dev@dpdk.org>; Tue, 5 Apr 2016 10:02:35 +0200 (CEST) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga103.fm.intel.com with ESMTP; 05 Apr 2016 01:02:18 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,443,1455004800"; d="scan'208";a="79227137" Received: from irvmail001.ir.intel.com ([163.33.26.43]) by fmsmga004.fm.intel.com with ESMTP; 05 Apr 2016 01:02:08 -0700 Received: from linux.site (sisvmlab045.ir.intel.com [10.237.216.57]) by irvmail001.ir.intel.com (8.14.3/8.13.6/MailSET/Hub) with ESMTP id u35827h4029128; Tue, 5 Apr 2016 09:02:07 +0100 Received: by linux.site (Postfix, from userid 11342333) id 8B67BE3BC2; Tue, 5 Apr 2016 08:53:21 +0100 (IST) From: Fiona Trahe <fiona.trahe@intel.com> To: dev@dpdk.org Cc: Declan.doherty@intel.com, Fiona Trahe <fiona.trahe@intel.com> Date: Tue, 5 Apr 2016 08:53:13 +0100 Message-Id: <1459842793-18071-1-git-send-email-fiona.trahe@intel.com> X-Mailer: git-send-email 1.7.0.7 Subject: [dpdk-dev] [PATCH] cryptodev: Remove EXPERIMENTAL label X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> |
Commit Message
Fiona Trahe
April 5, 2016, 7:53 a.m. UTC
The cryptodev API was introduced in the DPDK 2.2 release.
Since then it has
- been reviewed and iterated for the DPDK 16.04 release
- had extensive use by the l2fwd-crypto app,
the ipsec-secgw example app,
the test app.
We believe it is now stable and the EXPERIMENTAL label should be removed.
Signed-off-by: Fiona Trahe <fiona.trahe@intel.com>
---
MAINTAINERS | 2 +-
config/common_base | 1 -
lib/librte_cryptodev/rte_cryptodev.h | 2 --
3 files changed, 1 insertion(+), 4 deletions(-)
Comments
2016-04-05 08:53, Fiona Trahe: > The cryptodev API was introduced in the DPDK 2.2 release. > Since then it has > - been reviewed and iterated for the DPDK 16.04 release > - had extensive use by the l2fwd-crypto app, > the ipsec-secgw example app, > the test app. > We believe it is now stable and the EXPERIMENTAL label should be removed. Are you sure sure? :) It means you will try hard to not change the API anymore or you'll need a deprecation notice strongly agreed (outside of your team). > * Defines RTE Crypto Device APIs for the provisioning of cipher and > * authentication operations. > * This empty line can be removed. > - * @b EXPERIMENTAL: this API may change without prior notice > - * > */
> -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Tuesday, April 05, 2016 9:48 AM > To: Trahe, Fiona > Cc: dev@dpdk.org; Doherty, Declan > Subject: Re: [dpdk-dev] [PATCH] cryptodev: Remove EXPERIMENTAL label > > 2016-04-05 08:53, Fiona Trahe: > > The cryptodev API was introduced in the DPDK 2.2 release. > > Since then it has > > - been reviewed and iterated for the DPDK 16.04 release > > - had extensive use by the l2fwd-crypto app, > > the ipsec-secgw example app, > > the test app. > > We believe it is now stable and the EXPERIMENTAL label should be removed. > > Are you sure sure? :) > It means you will try hard to not change the API anymore or you'll need a > deprecation notice strongly agreed (outside of your team). We're sure sure :) > > > * Defines RTE Crypto Device APIs for the provisioning of cipher and > > * authentication operations. > > * > > This empty line can be removed. > > > - * @b EXPERIMENTAL: this API may change without prior notice > > - * > > */ A v2 without the empty line will follow shortly.
2016-04-05 09:48, Trahe, Fiona: > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > 2016-04-05 08:53, Fiona Trahe: > > > The cryptodev API was introduced in the DPDK 2.2 release. > > > Since then it has > > > - been reviewed and iterated for the DPDK 16.04 release > > > - had extensive use by the l2fwd-crypto app, > > > the ipsec-secgw example app, > > > the test app. > > > We believe it is now stable and the EXPERIMENTAL label should be removed. > > > > Are you sure sure? :) > > It means you will try hard to not change the API anymore or you'll need a > > deprecation notice strongly agreed (outside of your team). > > We're sure sure :) I think we could change the namespace before making this API stable. What about using a dpdk_ prefix instead of rte_ ? (and some macros have CRYPTODEV or CDEV prefixes)
I'd like people opinion of Thomas proposal to have all new libraries use a dpdk_ prefix instead of rte_*. Although I agree that dpdk_ would probably make sense, I don't like the ascetics of inconsistent prefixes on dpdk libraries. Any comments? 2016-04-05 09:48, Trahe, Fiona: > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > 2016-04-05 08:53, Fiona Trahe: > > > The cryptodev API was introduced in the DPDK 2.2 release. > > > Since then it has > > > - been reviewed and iterated for the DPDK 16.04 release > > > - had extensive use by the l2fwd-crypto app, > > > the ipsec-secgw example app, > > > the test app. > > > We believe it is now stable and the EXPERIMENTAL label should be removed. > > > > Are you sure sure? :) > > It means you will try hard to not change the API anymore or you'll need a > > deprecation notice strongly agreed (outside of your team). > > We're sure sure :) I think we could change the namespace before making this API stable. What about using a dpdk_ prefix instead of rte_ ? (and some macros have CRYPTODEV or CDEV prefixes)
> -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Declan Doherty > Sent: Tuesday, April 05, 2016 2:29 PM > To: dev@dpdk.org > Subject: [dpdk-dev] Change new libraries to have dpdk_ prefix instead of rte_ > > I'd like people opinion of Thomas proposal to have all new libraries use > a dpdk_ prefix instead of rte_*. Although I agree that dpdk_ would > probably make sense, I don't like the ascetics of inconsistent prefixes > on dpdk libraries. Any comments? I suppose it is a bit strange to have rte_ prefix for one set of libraries, and dpdk_ prefix for others. If we'd decide to change the prefix, then my vote would be to do that for all dpdk libraries at once. BTW, why do we need to change it at all? 'rte_' is probably not the best one, but at least it is well known/used. Konstantin > > > > > 2016-04-05 09:48, Trahe, Fiona: > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > > 2016-04-05 08:53, Fiona Trahe: > > > > The cryptodev API was introduced in the DPDK 2.2 release. > > > > Since then it has > > > > - been reviewed and iterated for the DPDK 16.04 release > > > > - had extensive use by the l2fwd-crypto app, > > > > the ipsec-secgw example app, > > > > the test app. > > > > We believe it is now stable and the EXPERIMENTAL label should be removed. > > > > > > Are you sure sure? :) > > > It means you will try hard to not change the API anymore or you'll need a > > > deprecation notice strongly agreed (outside of your team). > > > > We're sure sure :) > > I think we could change the namespace before making this API stable. > What about using a dpdk_ prefix instead of rte_ ? > (and some macros have CRYPTODEV or CDEV prefixes) >
Thanks for commenting and making the debate alive :) 2016-04-05 14:03, Ananyev, Konstantin: > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Declan Doherty > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > > I think we could change the namespace before making this API stable. > > > What about using a dpdk_ prefix instead of rte_ ? > > > > I'd like people opinion of Thomas proposal to have all new libraries use > > a dpdk_ prefix instead of rte_*. Although I agree that dpdk_ would > > probably make sense, I don't like the ascetics of inconsistent prefixes > > on dpdk libraries. Any comments? > > I suppose it is a bit strange to have rte_ prefix for one set of libraries, > and dpdk_ prefix for others. Don't you think it is strange to have a prefix not related with the public project name? Is it strange to have some functions without any prefix at all? (examples in rte_ether.h) > If we'd decide to change the prefix, then my vote would be to do > that for all dpdk libraries at once. > BTW, why do we need to change it at all? > 'rte_' is probably not the best one, but at least it is well known/used. Well known, really? The question is how large is the audience we target. Please see my other email: http://dpdk.org/ml/archives/dev/2016-April/037048.html
> >> -----Original Message----- >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Declan Doherty >> Sent: Tuesday, April 05, 2016 2:29 PM >> To: dev@dpdk.org >> Subject: [dpdk-dev] Change new libraries to have dpdk_ prefix instead of rte_ >> >> I'd like people opinion of Thomas proposal to have all new libraries use >> a dpdk_ prefix instead of rte_*. Although I agree that dpdk_ would >> probably make sense, I don't like the ascetics of inconsistent prefixes >> on dpdk libraries. Any comments? > >I suppose it is a bit strange to have rte_ prefix for one set of libraries, >and dpdk_ prefix for others. >If we'd decide to change the prefix, then my vote would be to do >that for all dpdk libraries at once. >BTW, why do we need to change it at all? >'rte_' is probably not the best one, but at least it is well known/used. >Konstantin I agree with Thomas as a Type One like person I would like to change it too, but think Konstantin’s point is very valid and we do not need to change existing APIs. I could live with changing the new libraries only, but then we get into the multiple prefixes problem :-( > > >> >> >> >> >> 2016-04-05 09:48, Trahe, Fiona: >> > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] >> > > 2016-04-05 08:53, Fiona Trahe: >> > > > The cryptodev API was introduced in the DPDK 2.2 release. >> > > > Since then it has >> > > > - been reviewed and iterated for the DPDK 16.04 release >> > > > - had extensive use by the l2fwd-crypto app, >> > > > the ipsec-secgw example app, >> > > > the test app. >> > > > We believe it is now stable and the EXPERIMENTAL label should be removed. >> > > >> > > Are you sure sure? :) >> > > It means you will try hard to not change the API anymore or you'll need a >> > > deprecation notice strongly agreed (outside of your team). >> > >> > We're sure sure :) >> >> I think we could change the namespace before making this API stable. >> What about using a dpdk_ prefix instead of rte_ ? >> (and some macros have CRYPTODEV or CDEV prefixes) >> > > Regards, Keith
diff --git a/MAINTAINERS b/MAINTAINERS index 85d72ca..a7570cd 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -231,7 +231,7 @@ M: Thomas Monjalon <thomas.monjalon@6wind.com> F: lib/librte_ether/ F: scripts/test-null.sh -Crypto API - EXPERIMENTAL +Crypto API M: Declan Doherty <declan.doherty@intel.com> F: lib/librte_cryptodev/ F: app/test/test_cryptodev* diff --git a/config/common_base b/config/common_base index abd6a64..0124e86 100644 --- a/config/common_base +++ b/config/common_base @@ -327,7 +327,6 @@ 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 diff --git a/lib/librte_cryptodev/rte_cryptodev.h b/lib/librte_cryptodev/rte_cryptodev.h index b599c95..1427dcf 100644 --- a/lib/librte_cryptodev/rte_cryptodev.h +++ b/lib/librte_cryptodev/rte_cryptodev.h @@ -40,8 +40,6 @@ * Defines RTE Crypto Device APIs for the provisioning of cipher and * authentication operations. * - * @b EXPERIMENTAL: this API may change without prior notice - * */ #ifdef __cplusplus