[dpdk-dev] [PATCH v5 1/2] cryptodev: add chacha20-poly1305 aead algorithm

[dpdk-dev] [PATCH v5 1/2] cryptodev: add chacha20-poly1305 aead algorithm

[Arek Kusztal]

This patch adds Chacha20-Poly1305 AEAD algorithm to Cryptodev.

Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
Acked-by: Fiona Trahe <fiona.trahe@intel.com>
Acked-by: Anoob Joseph <anoobj@marvell.com>
Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
---
v3:
- rebased against 20.05
v4:
- rebased again against 20.05
v5:
- resent with versioning patch which needed v5

 doc/guides/cryptodevs/features/default.ini | 13 +++++++------
 doc/guides/rel_notes/release_20_05.rst     |  4 ++++
 lib/librte_cryptodev/rte_crypto_sym.h      |  9 +++++++++
 lib/librte_cryptodev/rte_cryptodev.c       |  1 +
 4 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/doc/guides/cryptodevs/features/default.ini b/doc/guides/cryptodevs/features/default.ini
index 118479d..800bcf8 100644
--- a/doc/guides/cryptodevs/features/default.ini
+++ b/doc/guides/cryptodevs/features/default.ini
@@ -95,12 +95,13 @@ SHA3_512 HMAC   =
 ; Supported AEAD algorithms of a default crypto driver.
 ;
 [AEAD]
-AES GCM (128) =
-AES GCM (192) =
-AES GCM (256) =
-AES CCM (128) =
-AES CCM (192) =
-AES CCM (256) =
+AES GCM (128)     =
+AES GCM (192)     =
+AES GCM (256)     =
+AES CCM (128)     =
+AES CCM (192)     =
+AES CCM (256)     =
+CHACHA20-POLY1305 =
 ;
 ; Supported Asymmetric algorithms of a default crypto driver.
 ;
diff --git a/doc/guides/rel_notes/release_20_05.rst b/doc/guides/rel_notes/release_20_05.rst
index b124c3f..88396e8 100644
--- a/doc/guides/rel_notes/release_20_05.rst
+++ b/doc/guides/rel_notes/release_20_05.rst
@@ -212,6 +212,10 @@ New Features
   * Added IPsec inbound load-distribution support for ipsec-secgw application
     using NIC load distribution feature(Flow Director).
 
+* **Added Chacha20-Poly1305 algorithm to Cryptodev API.**
+
+  Chacha20-Poly1305 AEAD algorithm can now be supported in Cryptodev.
+
 
 Removed Items
 -------------
diff --git a/lib/librte_cryptodev/rte_crypto_sym.h b/lib/librte_cryptodev/rte_crypto_sym.h
index 9e887c1..d9585ec 100644
--- a/lib/librte_cryptodev/rte_crypto_sym.h
+++ b/lib/librte_cryptodev/rte_crypto_sym.h
@@ -409,6 +409,8 @@ enum rte_crypto_aead_algorithm {
 	/**< AES algorithm in CCM mode. */
 	RTE_CRYPTO_AEAD_AES_GCM,
 	/**< AES algorithm in GCM mode. */
+	RTE_CRYPTO_AEAD_CHACHA20_POLY1305,
+	/**< Chacha20 cipher with poly1305 authenticator */
 	RTE_CRYPTO_AEAD_LIST_END
 };
 
@@ -452,6 +454,11 @@ struct rte_crypto_aead_xform {
 		 * be allocated, even though the length field will
 		 * have a value less than this.
 		 *
+		 * - For Chacha20-Poly1305 it is 96-bit nonce.
+		 * PMD sets initial counter for Poly1305 key generation
+		 * part to 0 and for Chacha20 encryption to 1 as per
+		 * rfc8439 2.8. AEAD construction.
+		 *
 		 * For optimum performance, the data pointed to SHOULD
 		 * be 8-byte aligned.
 		 */
@@ -468,6 +475,8 @@ struct rte_crypto_aead_xform {
 		 *
 		 * - For CCM mode, this is the length of the nonce,
 		 * which can be in the range 7 to 13 inclusive.
+		 *
+		 * - For Chacha20-Poly1305 this field is always 12.
 		 */
 	} iv;	/**< Initialisation vector parameters */
 
diff --git a/lib/librte_cryptodev/rte_cryptodev.c b/lib/librte_cryptodev/rte_cryptodev.c
index 7693eb6..a499c47 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -152,6 +152,7 @@ const char *
 rte_crypto_aead_algorithm_strings[] = {
 	[RTE_CRYPTO_AEAD_AES_CCM]	= "aes-ccm",
 	[RTE_CRYPTO_AEAD_AES_GCM]	= "aes-gcm",
+	[RTE_CRYPTO_AEAD_CHACHA20_POLY1305] = "chacha20-poly1305"
 };
 
 /**
-- 
2.1.0

[dpdk-dev] [PATCH v5 2/2] cryptodev: version cryptodev info get function

[Arek Kusztal]

This patch adds versioned function rte_cryptodev_info_get()
to prevent some issues with ABI policy.
Node v21 works in same way as before, returning driver capabilities
directly to the API caller. These capabilities may include new elements
not part of the v20 ABI.
Node v20 function maintains compatibility with v20 ABI releases
by stripping out elements not supported in v20 ABI. Because
rte_cryptodev_info_get is called by other API functions,
rte_cryptodev_sym_capability_get function is versioned the same way.

Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
v2:
- changed version numbers of symbols to 20.0.2
v3:
- added v2/v3 informations
- changed version numbers of symbols to 21
v4:
- fixed clang build by movind binding default symbol
- implemented mailing list comments
- added abidiff tool suppression entries
v5:
- fixed meson build

 devtools/libabigail.abignore                   |   8 ++
 lib/librte_cryptodev/meson.build               |   1 +
 lib/librte_cryptodev/rte_cryptodev.c           | 147 ++++++++++++++++++++++++-
 lib/librte_cryptodev/rte_cryptodev.h           |  34 +++++-
 lib/librte_cryptodev/rte_cryptodev_version.map |   7 ++
 5 files changed, 191 insertions(+), 6 deletions(-)

diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
index 1911890..e479e20 100644
--- a/devtools/libabigail.abignore
+++ b/devtools/libabigail.abignore
@@ -24,3 +24,11 @@
         type_kind = enum
         name = rte_eth_event_type
         changed_enumerators = RTE_ETH_EVENT_MAX
+; Ignore Cryptodev AEAD xform enum and AEAD xform strings change
+; due to addition of Chacha20-Poly1305
+[suppress_type]
+        type_kind = enum
+        name = rte_crypto_aead_algorithm
+        changed_enumerators = RTE_CRYPTO_AEAD_LIST_END
+[suppress_variable]
+        name = rte_crypto_aead_algorithm_strings
diff --git a/lib/librte_cryptodev/meson.build b/lib/librte_cryptodev/meson.build
index c4c6b3b..df11440 100644
--- a/lib/librte_cryptodev/meson.build
+++ b/lib/librte_cryptodev/meson.build
@@ -1,6 +1,7 @@
 # SPDX-License-Identifier: BSD-3-Clause
 # Copyright(c) 2017-2019 Intel Corporation
 
+use_function_versioning = true
 sources = files('rte_cryptodev.c', 'rte_cryptodev_pmd.c', 'cryptodev_trace_points.c')
 headers = files('rte_cryptodev.h',
 	'rte_cryptodev_pmd.h',
diff --git a/lib/librte_cryptodev/rte_cryptodev.c b/lib/librte_cryptodev/rte_cryptodev.c
index a499c47..e4a7b71 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -36,6 +36,8 @@
 #include <rte_errno.h>
 #include <rte_spinlock.h>
 #include <rte_string_fns.h>
+#include <rte_compat.h>
+#include <rte_function_versioning.h>
 
 #include "rte_crypto.h"
 #include "rte_cryptodev.h"
@@ -57,6 +59,14 @@ static struct rte_cryptodev_global cryptodev_globals = {
 /* spinlock for crypto device callbacks */
 static rte_spinlock_t rte_cryptodev_cb_lock = RTE_SPINLOCK_INITIALIZER;
 
+static const struct rte_cryptodev_capabilities
+		cryptodev_undefined_capabilities[] = {
+		RTE_CRYPTODEV_END_OF_CAPABILITIES_LIST()
+};
+
+static struct rte_cryptodev_capabilities
+		*capability_copy[RTE_CRYPTO_MAX_DEVS];
+static uint8_t is_capability_checked[RTE_CRYPTO_MAX_DEVS];
 
 /**
  * The user application callback description.
@@ -281,15 +291,15 @@ rte_crypto_auth_operation_strings[] = {
 		[RTE_CRYPTO_AUTH_OP_GENERATE]	= "generate"
 };
 
-const struct rte_cryptodev_symmetric_capability *
-rte_cryptodev_sym_capability_get(uint8_t dev_id,
+const struct rte_cryptodev_symmetric_capability __vsym *
+rte_cryptodev_sym_capability_get_v20(uint8_t dev_id,
 		const struct rte_cryptodev_sym_capability_idx *idx)
 {
 	const struct rte_cryptodev_capabilities *capability;
 	struct rte_cryptodev_info dev_info;
 	int i = 0;
 
-	rte_cryptodev_info_get(dev_id, &dev_info);
+	rte_cryptodev_info_get_v20(dev_id, &dev_info);
 
 	while ((capability = &dev_info.capabilities[i++])->op !=
 			RTE_CRYPTO_OP_TYPE_UNDEFINED) {
@@ -313,8 +323,47 @@ rte_cryptodev_sym_capability_get(uint8_t dev_id,
 	}
 
 	return NULL;
+}
+VERSION_SYMBOL(rte_cryptodev_sym_capability_get, _v20, 20.0);
+
+const struct rte_cryptodev_symmetric_capability __vsym *
+rte_cryptodev_sym_capability_get_v21(uint8_t dev_id,
+		const struct rte_cryptodev_sym_capability_idx *idx)
+{
+	const struct rte_cryptodev_capabilities *capability;
+	struct rte_cryptodev_info dev_info;
+	int i = 0;
+
+	rte_cryptodev_info_get(dev_id, &dev_info);
+
+	while ((capability = &dev_info.capabilities[i++])->op !=
+			RTE_CRYPTO_OP_TYPE_UNDEFINED) {
+		if (capability->op != RTE_CRYPTO_OP_TYPE_SYMMETRIC)
+			continue;
 
+		if (capability->sym.xform_type != idx->type)
+			continue;
+
+		if (idx->type == RTE_CRYPTO_SYM_XFORM_AUTH &&
+			capability->sym.auth.algo == idx->algo.auth)
+			return &capability->sym;
+
+		if (idx->type == RTE_CRYPTO_SYM_XFORM_CIPHER &&
+			capability->sym.cipher.algo == idx->algo.cipher)
+			return &capability->sym;
+
+		if (idx->type == RTE_CRYPTO_SYM_XFORM_AEAD &&
+				capability->sym.aead.algo == idx->algo.aead)
+			return &capability->sym;
+	}
+
+	return NULL;
 }
+MAP_STATIC_SYMBOL(const struct rte_cryptodev_symmetric_capability *
+		rte_cryptodev_sym_capability_get(uint8_t dev_id,
+		const struct rte_cryptodev_sym_capability_idx *idx),
+		rte_cryptodev_sym_capability_get_v21);
+BIND_DEFAULT_SYMBOL(rte_cryptodev_sym_capability_get, _v21, 21);
 
 static int
 param_range_check(uint16_t size, const struct rte_crypto_param_range *range)
@@ -1016,6 +1065,12 @@ rte_cryptodev_close(uint8_t dev_id)
 	retval = (*dev->dev_ops->dev_close)(dev);
 	rte_cryptodev_trace_close(dev_id, retval);
 
+	if (capability_copy[dev_id]) {
+		free(capability_copy[dev_id]);
+		capability_copy[dev_id] = NULL;
+	}
+	is_capability_checked[dev_id] = 0;
+
 	if (retval < 0)
 		return retval;
 
@@ -1129,9 +1184,61 @@ rte_cryptodev_stats_reset(uint8_t dev_id)
 	(*dev->dev_ops->stats_reset)(dev);
 }
 
+static void
+get_v20_capabilities(uint8_t dev_id, struct rte_cryptodev_info *dev_info)
+{
+	const struct rte_cryptodev_capabilities *capability;
+	uint8_t found_invalid_capa = 0;
+	uint8_t counter = 0;
+
+	for (capability = dev_info->capabilities;
+			capability->op != RTE_CRYPTO_OP_TYPE_UNDEFINED;
+			++capability, ++counter) {
+		if (capability->op == RTE_CRYPTO_OP_TYPE_SYMMETRIC &&
+				capability->sym.xform_type ==
+					RTE_CRYPTO_SYM_XFORM_AEAD
+				&& capability->sym.aead.algo >=
+				RTE_CRYPTO_AEAD_CHACHA20_POLY1305) {
+			found_invalid_capa = 1;
+			counter--;
+		}
+	}
+	is_capability_checked[dev_id] = 1;
+	if (!found_invalid_capa)
+		return;
+	capability_copy[dev_id] = malloc(counter *
+		sizeof(struct rte_cryptodev_capabilities));
+	if (capability_copy[dev_id] == NULL) {
+		 /*
+		  * error case - no memory to store the trimmed
+		  * list, so have to return an empty list
+		  */
+		dev_info->capabilities =
+			cryptodev_undefined_capabilities;
+		is_capability_checked[dev_id] = 0;
+	} else {
+		counter = 0;
+		for (capability = dev_info->capabilities;
+				capability->op !=
+				RTE_CRYPTO_OP_TYPE_UNDEFINED;
+				capability++) {
+			if (!(capability->op ==
+				RTE_CRYPTO_OP_TYPE_SYMMETRIC
+				&& capability->sym.xform_type ==
+				RTE_CRYPTO_SYM_XFORM_AEAD
+				&& capability->sym.aead.algo >=
+				RTE_CRYPTO_AEAD_CHACHA20_POLY1305)) {
+				capability_copy[dev_id][counter++] =
+						*capability;
+			}
+		}
+		dev_info->capabilities =
+				capability_copy[dev_id];
+	}
+}
 
-void
-rte_cryptodev_info_get(uint8_t dev_id, struct rte_cryptodev_info *dev_info)
+void __vsym
+rte_cryptodev_info_get_v20(uint8_t dev_id, struct rte_cryptodev_info *dev_info)
 {
 	struct rte_cryptodev *dev;
 
@@ -1147,10 +1254,40 @@ rte_cryptodev_info_get(uint8_t dev_id, struct rte_cryptodev_info *dev_info)
 	RTE_FUNC_PTR_OR_RET(*dev->dev_ops->dev_infos_get);
 	(*dev->dev_ops->dev_infos_get)(dev, dev_info);
 
+	if (capability_copy[dev_id] == NULL) {
+		if (!is_capability_checked[dev_id])
+			get_v20_capabilities(dev_id, dev_info);
+	} else
+		dev_info->capabilities = capability_copy[dev_id];
+
 	dev_info->driver_name = dev->device->driver->name;
 	dev_info->device = dev->device;
 }
+VERSION_SYMBOL(rte_cryptodev_info_get, _v20, 20.0);
 
+void __vsym
+rte_cryptodev_info_get_v21(uint8_t dev_id, struct rte_cryptodev_info *dev_info)
+{
+	struct rte_cryptodev *dev;
+
+	if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
+		CDEV_LOG_ERR("Invalid dev_id=%d", dev_id);
+		return;
+	}
+
+	dev = &rte_crypto_devices[dev_id];
+
+	memset(dev_info, 0, sizeof(struct rte_cryptodev_info));
+
+	RTE_FUNC_PTR_OR_RET(*dev->dev_ops->dev_infos_get);
+	(*dev->dev_ops->dev_infos_get)(dev, dev_info);
+
+	dev_info->driver_name = dev->device->driver->name;
+	dev_info->device = dev->device;
+}
+MAP_STATIC_SYMBOL(void rte_cryptodev_info_get(uint8_t dev_id,
+	struct rte_cryptodev_info *dev_info), rte_cryptodev_info_get_v21);
+BIND_DEFAULT_SYMBOL(rte_cryptodev_info_get, _v21, 21);
 
 int
 rte_cryptodev_callback_register(uint8_t dev_id,
diff --git a/lib/librte_cryptodev/rte_cryptodev.h b/lib/librte_cryptodev/rte_cryptodev.h
index 3dbb5ce..d8e8e46 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -219,6 +219,14 @@ struct rte_cryptodev_asym_capability_idx {
  *   - Return NULL if the capability not exist.
  */
 const struct rte_cryptodev_symmetric_capability *
+rte_cryptodev_sym_capability_get_v20(uint8_t dev_id,
+		const struct rte_cryptodev_sym_capability_idx *idx);
+
+const struct rte_cryptodev_symmetric_capability *
+rte_cryptodev_sym_capability_get_v21(uint8_t dev_id,
+		const struct rte_cryptodev_sym_capability_idx *idx);
+
+const struct rte_cryptodev_symmetric_capability *
 rte_cryptodev_sym_capability_get(uint8_t dev_id,
 		const struct rte_cryptodev_sym_capability_idx *idx);
 
@@ -762,9 +770,33 @@ rte_cryptodev_stats_reset(uint8_t dev_id);
  * the last valid element has it's op field set to
  * RTE_CRYPTO_OP_TYPE_UNDEFINED.
  */
-extern void
+
+void
 rte_cryptodev_info_get(uint8_t dev_id, struct rte_cryptodev_info *dev_info);
 
+/* An extra element RTE_CRYPTO_AEAD_CHACHA20_POLY1305 is added
+ * to enum rte_crypto_aead_algorithm, also changing the value of
+ *  RTE_CRYPTO_AEAD_LIST_END. To maintain ABI compatibility with applications
+ * which linked against earlier versions, preventing them, for example, from
+ * picking up the new value and using it to index into an array sized too small
+ * for it, it is necessary to have two versions of rte_cryptodev_info_get()
+ * The latest version just returns directly the capabilities retrieved from
+ * the device. The compatible version inspects the capabilities retrieved
+ * from the device, but only returns them directly if the new value
+ * is not included. If the new value is included, it allocates space
+ * for a copy of the device capabilities, trims the new value from this
+ * and returns this copy. It only needs to do this once per device.
+ * For the corner case of a corner case when the alloc may fail,
+ * an empty capability list is returned, as there is no mechanism to return
+ * an error and adding such a mechanism would itself be an ABI breakage.
+ * The compatible version can be removed after the next major ABI release.
+ */
+
+void
+rte_cryptodev_info_get_v20(uint8_t dev_id, struct rte_cryptodev_info *dev_info);
+
+void
+rte_cryptodev_info_get_v21(uint8_t dev_id, struct rte_cryptodev_info *dev_info);
 
 /**
  * Register a callback function for specific device id.
diff --git a/lib/librte_cryptodev/rte_cryptodev_version.map b/lib/librte_cryptodev/rte_cryptodev_version.map
index 87f5cd1..07a2d2f 100644
--- a/lib/librte_cryptodev/rte_cryptodev_version.map
+++ b/lib/librte_cryptodev/rte_cryptodev_version.map
@@ -58,6 +58,13 @@ DPDK_20.0 {
 	local: *;
 };
 
+DPDK_21 {
+	global:
+	rte_cryptodev_info_get;
+	rte_cryptodev_sym_capability_get;
+} DPDK_20.0;
+
+
 EXPERIMENTAL {
 	global:
 
-- 
2.1.0

Re: [dpdk-dev] [PATCH v5 2/2] cryptodev: version cryptodev info get function

[Ray Kinsella]

On 07/05/2020 11:57, Arek Kusztal wrote:
> This patch adds versioned function rte_cryptodev_info_get()
> to prevent some issues with ABI policy.
> Node v21 works in same way as before, returning driver capabilities
> directly to the API caller. These capabilities may include new elements
> not part of the v20 ABI.
> Node v20 function maintains compatibility with v20 ABI releases
> by stripping out elements not supported in v20 ABI. Because
> rte_cryptodev_info_get is called by other API functions,
> rte_cryptodev_sym_capability_get function is versioned the same way.
> 
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> ---
> v2:
> - changed version numbers of symbols to 20.0.2
> v3:
> - added v2/v3 informations
> - changed version numbers of symbols to 21
> v4:
> - fixed clang build by movind binding default symbol
> - implemented mailing list comments
> - added abidiff tool suppression entries
> v5:
> - fixed meson build
> 
>  devtools/libabigail.abignore                   |   8 ++
>  lib/librte_cryptodev/meson.build               |   1 +
>  lib/librte_cryptodev/rte_cryptodev.c           | 147 ++++++++++++++++++++++++-
>  lib/librte_cryptodev/rte_cryptodev.h           |  34 +++++-
>  lib/librte_cryptodev/rte_cryptodev_version.map |   7 ++
>  5 files changed, 191 insertions(+), 6 deletions(-)
> 
[SNIP]

Acked-by: Ray Kinsella <mdr@ashroe.eu>

Re: [dpdk-dev] [PATCH v5 2/2] cryptodev: version cryptodev info get function

[Akhil Goyal]

Hi Ray/Arek,

I still see Incompatible cryptodev even after update in the abignore list.
I checked it with ./devtools/validate-abi.sh
NOTICE: ABI may be incompatible, check reports/logs for details.
NOTICE: Incompatible list:  librte_cryptodev.so

Did I miss something?


> 
> On 07/05/2020 11:57, Arek Kusztal wrote:
> > This patch adds versioned function rte_cryptodev_info_get()
> > to prevent some issues with ABI policy.
> > Node v21 works in same way as before, returning driver capabilities
> > directly to the API caller. These capabilities may include new elements
> > not part of the v20 ABI.
> > Node v20 function maintains compatibility with v20 ABI releases
> > by stripping out elements not supported in v20 ABI. Because
> > rte_cryptodev_info_get is called by other API functions,
> > rte_cryptodev_sym_capability_get function is versioned the same way.
> >
> > Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> > ---
> > v2:
> > - changed version numbers of symbols to 20.0.2
> > v3:
> > - added v2/v3 informations
> > - changed version numbers of symbols to 21
> > v4:
> > - fixed clang build by movind binding default symbol
> > - implemented mailing list comments
> > - added abidiff tool suppression entries
> > v5:
> > - fixed meson build
> >
> >  devtools/libabigail.abignore                   |   8 ++
> >  lib/librte_cryptodev/meson.build               |   1 +
> >  lib/librte_cryptodev/rte_cryptodev.c           | 147
> ++++++++++++++++++++++++-
> >  lib/librte_cryptodev/rte_cryptodev.h           |  34 +++++-
> >  lib/librte_cryptodev/rte_cryptodev_version.map |   7 ++
> >  5 files changed, 191 insertions(+), 6 deletions(-)
> >
> [SNIP]
> 
> Acked-by: Ray Kinsella <mdr@ashroe.eu>

Re: [dpdk-dev] [PATCH v5 2/2] cryptodev: version cryptodev info get function

[Ray Kinsella]

Hi Akhil,

I didn't see this - checking again.

Ray K

On 09/05/2020 22:11, Akhil Goyal wrote:
> Hi Ray/Arek,
> 
> I still see Incompatible cryptodev even after update in the abignore list.
> I checked it with ./devtools/validate-abi.sh
> NOTICE: ABI may be incompatible, check reports/logs for details.
> NOTICE: Incompatible list:  librte_cryptodev.so
> 
> Did I miss something?
> 
> 
>>
>> On 07/05/2020 11:57, Arek Kusztal wrote:
>>> This patch adds versioned function rte_cryptodev_info_get()
>>> to prevent some issues with ABI policy.
>>> Node v21 works in same way as before, returning driver capabilities
>>> directly to the API caller. These capabilities may include new elements
>>> not part of the v20 ABI.
>>> Node v20 function maintains compatibility with v20 ABI releases
>>> by stripping out elements not supported in v20 ABI. Because
>>> rte_cryptodev_info_get is called by other API functions,
>>> rte_cryptodev_sym_capability_get function is versioned the same way.
>>>
>>> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
>>> ---
>>> v2:
>>> - changed version numbers of symbols to 20.0.2
>>> v3:
>>> - added v2/v3 informations
>>> - changed version numbers of symbols to 21
>>> v4:
>>> - fixed clang build by movind binding default symbol
>>> - implemented mailing list comments
>>> - added abidiff tool suppression entries
>>> v5:
>>> - fixed meson build
>>>
>>>  devtools/libabigail.abignore                   |   8 ++
>>>  lib/librte_cryptodev/meson.build               |   1 +
>>>  lib/librte_cryptodev/rte_cryptodev.c           | 147
>> ++++++++++++++++++++++++-
>>>  lib/librte_cryptodev/rte_cryptodev.h           |  34 +++++-
>>>  lib/librte_cryptodev/rte_cryptodev_version.map |   7 ++
>>>  5 files changed, 191 insertions(+), 6 deletions(-)
>>>
>> [SNIP]
>>
>> Acked-by: Ray Kinsella <mdr@ashroe.eu>

Re: [dpdk-dev] [PATCH v5 2/2] cryptodev: version cryptodev info get function

[Ray Kinsella]

Hi Akhil,

So 1st thing is that this that validate-abi uses "ABI Compliance Checker",
which does not use libabigail.ignore.

So you will end up with different results compared to using libabigail as follows:

DPDK_ABI_REF_DIR=<some absolute path> DPDK_ABI_REF_VERSION=v20.02 ./devtools/test-meson-builds.sh

I did check with the "ABI Compliance Checker" (I like this tool also), however I got the following 

NOTICE: No error detected, ABI is compatible.
INFO: Logs are in /root/src/dpdk/abi-check/abi-check.log
INFO: HTML reports are in /root/src/dpdk/abi-check/compat_reports directory

What references did you use with validate-abi.sh (I used v20.02 and HEAD).

Ray K

On 09/05/2020 22:11, Akhil Goyal wrote:
> Hi Ray/Arek,
> 
> I still see Incompatible cryptodev even after update in the abignore list.
> I checked it with ./devtools/validate-abi.sh
> NOTICE: ABI may be incompatible, check reports/logs for details.
> NOTICE: Incompatible list:  librte_cryptodev.so
> 
> Did I miss something?
> 
> 
>>
>> On 07/05/2020 11:57, Arek Kusztal wrote:
>>> This patch adds versioned function rte_cryptodev_info_get()
>>> to prevent some issues with ABI policy.
>>> Node v21 works in same way as before, returning driver capabilities
>>> directly to the API caller. These capabilities may include new elements
>>> not part of the v20 ABI.
>>> Node v20 function maintains compatibility with v20 ABI releases
>>> by stripping out elements not supported in v20 ABI. Because
>>> rte_cryptodev_info_get is called by other API functions,
>>> rte_cryptodev_sym_capability_get function is versioned the same way.
>>>
>>> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
>>> ---
>>> v2:
>>> - changed version numbers of symbols to 20.0.2
>>> v3:
>>> - added v2/v3 informations
>>> - changed version numbers of symbols to 21
>>> v4:
>>> - fixed clang build by movind binding default symbol
>>> - implemented mailing list comments
>>> - added abidiff tool suppression entries
>>> v5:
>>> - fixed meson build
>>>
>>>  devtools/libabigail.abignore                   |   8 ++
>>>  lib/librte_cryptodev/meson.build               |   1 +
>>>  lib/librte_cryptodev/rte_cryptodev.c           | 147
>> ++++++++++++++++++++++++-
>>>  lib/librte_cryptodev/rte_cryptodev.h           |  34 +++++-
>>>  lib/librte_cryptodev/rte_cryptodev_version.map |   7 ++
>>>  5 files changed, 191 insertions(+), 6 deletions(-)
>>>
>> [SNIP]
>>
>> Acked-by: Ray Kinsella <mdr@ashroe.eu>

Re: [dpdk-dev] [PATCH v5 2/2] cryptodev: version cryptodev info get function

[Akhil Goyal]

Hi Ray,

Previously, I only ran the script for the 2 patches.

./devtools/validate-abi.sh <commit id previous to these two patches> HEAD

However when I run for v20.02 and HEAD, the list is quite big. I believe most of them are either experimental or internal PMD. But cryptodev is still there.

NOTICE: abi-compliance-checker returned 1
NOTICE: ABI may be incompatible, check reports/logs for details.
NOTICE: Incompatible list:  librte_bbdev.so librte_common_iavf.so librte_common_octeontx2.so librte_cryptodev.so librte_eal.so librte_efd.so librte_eventdev.so librte_hash.so librte_ipsec.so librte_meter.so librte_pdump.so librte_pmd_crypto_scheduler.so librte_pmd_dpaa2_sec.so librte_pmd_dpaa_sec.so librte_pmd_ring.so librte_ring.so librte_vhost.so

Regards,
Akhil

> -----Original Message-----
> From: Ray Kinsella <mdr@ashroe.eu>
> Sent: Monday, May 11, 2020 1:18 PM
> To: Akhil Goyal <akhil.goyal@nxp.com>; Arek Kusztal
> <arkadiuszx.kusztal@intel.com>; dev@dpdk.org
> Cc: fiona.trahe@intel.com; ray.kinsella@intel.com; bruce.richardson@intel.com
> Subject: Re: [dpdk-dev] [PATCH v5 2/2] cryptodev: version cryptodev info get
> function
> 
> Hi Akhil,
> 
> So 1st thing is that this that validate-abi uses "ABI Compliance Checker",
> which does not use libabigail.ignore.
> 
> So you will end up with different results compared to using libabigail as follows:
> 
> DPDK_ABI_REF_DIR=<some absolute path>
> DPDK_ABI_REF_VERSION=v20.02 ./devtools/test-meson-builds.sh
> 
> I did check with the "ABI Compliance Checker" (I like this tool also), however I
> got the following
> 
> NOTICE: No error detected, ABI is compatible.
> INFO: Logs are in /root/src/dpdk/abi-check/abi-check.log
> INFO: HTML reports are in /root/src/dpdk/abi-check/compat_reports directory
> 
> What references did you use with validate-abi.sh (I used v20.02 and HEAD).
> 
> Ray K
> 
> On 09/05/2020 22:11, Akhil Goyal wrote:
> > Hi Ray/Arek,
> >
> > I still see Incompatible cryptodev even after update in the abignore list.
> > I checked it with ./devtools/validate-abi.sh
> > NOTICE: ABI may be incompatible, check reports/logs for details.
> > NOTICE: Incompatible list:  librte_cryptodev.so
> >
> > Did I miss something?
> >
> >
> >>
> >> On 07/05/2020 11:57, Arek Kusztal wrote:
> >>> This patch adds versioned function rte_cryptodev_info_get()
> >>> to prevent some issues with ABI policy.
> >>> Node v21 works in same way as before, returning driver capabilities
> >>> directly to the API caller. These capabilities may include new elements
> >>> not part of the v20 ABI.
> >>> Node v20 function maintains compatibility with v20 ABI releases
> >>> by stripping out elements not supported in v20 ABI. Because
> >>> rte_cryptodev_info_get is called by other API functions,
> >>> rte_cryptodev_sym_capability_get function is versioned the same way.
> >>>
> >>> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> >>> ---
> >>> v2:
> >>> - changed version numbers of symbols to 20.0.2
> >>> v3:
> >>> - added v2/v3 informations
> >>> - changed version numbers of symbols to 21
> >>> v4:
> >>> - fixed clang build by movind binding default symbol
> >>> - implemented mailing list comments
> >>> - added abidiff tool suppression entries
> >>> v5:
> >>> - fixed meson build
> >>>
> >>>  devtools/libabigail.abignore                   |   8 ++
> >>>  lib/librte_cryptodev/meson.build               |   1 +
> >>>  lib/librte_cryptodev/rte_cryptodev.c           | 147
> >> ++++++++++++++++++++++++-
> >>>  lib/librte_cryptodev/rte_cryptodev.h           |  34 +++++-
> >>>  lib/librte_cryptodev/rte_cryptodev_version.map |   7 ++
> >>>  5 files changed, 191 insertions(+), 6 deletions(-)
> >>>
> >> [SNIP]
> >>
> >> Acked-by: Ray Kinsella <mdr@ashroe.eu>

Re: [dpdk-dev] [PATCH v5 2/2] cryptodev: version cryptodev info get function

[Akhil Goyal]

Hi Ray,

I have applied the series on dpdk-next-crypto  as per your validation of ABI.

Thomas,
Please validate this series at your end before applying to master. I am not too sure on the ABI stuff.

Regards,
Akhil

> -----Original Message-----
> From: Akhil Goyal
> Sent: Monday, May 11, 2020 1:48 PM
> To: 'Ray Kinsella' <mdr@ashroe.eu>; Arek Kusztal
> <arkadiuszx.kusztal@intel.com>; dev@dpdk.org
> Cc: fiona.trahe@intel.com; ray.kinsella@intel.com; bruce.richardson@intel.com
> Subject: RE: [dpdk-dev] [PATCH v5 2/2] cryptodev: version cryptodev info get
> function
> 
> Hi Ray,
> 
> Previously, I only ran the script for the 2 patches.
> 
> ./devtools/validate-abi.sh <commit id previous to these two patches> HEAD
> 
> However when I run for v20.02 and HEAD, the list is quite big. I believe most of
> them are either experimental or internal PMD. But cryptodev is still there.
> 
> NOTICE: abi-compliance-checker returned 1
> NOTICE: ABI may be incompatible, check reports/logs for details.
> NOTICE: Incompatible list:  librte_bbdev.so librte_common_iavf.so
> librte_common_octeontx2.so librte_cryptodev.so librte_eal.so librte_efd.so
> librte_eventdev.so librte_hash.so librte_ipsec.so librte_meter.so
> librte_pdump.so librte_pmd_crypto_scheduler.so librte_pmd_dpaa2_sec.so
> librte_pmd_dpaa_sec.so librte_pmd_ring.so librte_ring.so librte_vhost.so
> 
> Regards,
> Akhil
> 
> > -----Original Message-----
> > From: Ray Kinsella <mdr@ashroe.eu>
> > Sent: Monday, May 11, 2020 1:18 PM
> > To: Akhil Goyal <akhil.goyal@nxp.com>; Arek Kusztal
> > <arkadiuszx.kusztal@intel.com>; dev@dpdk.org
> > Cc: fiona.trahe@intel.com; ray.kinsella@intel.com;
> bruce.richardson@intel.com
> > Subject: Re: [dpdk-dev] [PATCH v5 2/2] cryptodev: version cryptodev info get
> > function
> >
> > Hi Akhil,
> >
> > So 1st thing is that this that validate-abi uses "ABI Compliance Checker",
> > which does not use libabigail.ignore.
> >
> > So you will end up with different results compared to using libabigail as follows:
> >
> > DPDK_ABI_REF_DIR=<some absolute path>
> > DPDK_ABI_REF_VERSION=v20.02 ./devtools/test-meson-builds.sh
> >
> > I did check with the "ABI Compliance Checker" (I like this tool also), however I
> > got the following
> >
> > NOTICE: No error detected, ABI is compatible.
> > INFO: Logs are in /root/src/dpdk/abi-check/abi-check.log
> > INFO: HTML reports are in /root/src/dpdk/abi-check/compat_reports
> directory
> >
> > What references did you use with validate-abi.sh (I used v20.02 and HEAD).
> >
> > Ray K
> >
> > On 09/05/2020 22:11, Akhil Goyal wrote:
> > > Hi Ray/Arek,
> > >
> > > I still see Incompatible cryptodev even after update in the abignore list.
> > > I checked it with ./devtools/validate-abi.sh
> > > NOTICE: ABI may be incompatible, check reports/logs for details.
> > > NOTICE: Incompatible list:  librte_cryptodev.so
> > >
> > > Did I miss something?
> > >
> > >
> > >>
> > >> On 07/05/2020 11:57, Arek Kusztal wrote:
> > >>> This patch adds versioned function rte_cryptodev_info_get()
> > >>> to prevent some issues with ABI policy.
> > >>> Node v21 works in same way as before, returning driver capabilities
> > >>> directly to the API caller. These capabilities may include new elements
> > >>> not part of the v20 ABI.
> > >>> Node v20 function maintains compatibility with v20 ABI releases
> > >>> by stripping out elements not supported in v20 ABI. Because
> > >>> rte_cryptodev_info_get is called by other API functions,
> > >>> rte_cryptodev_sym_capability_get function is versioned the same way.
> > >>>
> > >>> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> > >>> ---
> > >>> v2:
> > >>> - changed version numbers of symbols to 20.0.2
> > >>> v3:
> > >>> - added v2/v3 informations
> > >>> - changed version numbers of symbols to 21
> > >>> v4:
> > >>> - fixed clang build by movind binding default symbol
> > >>> - implemented mailing list comments
> > >>> - added abidiff tool suppression entries
> > >>> v5:
> > >>> - fixed meson build
> > >>>
> > >>>  devtools/libabigail.abignore                   |   8 ++
> > >>>  lib/librte_cryptodev/meson.build               |   1 +
> > >>>  lib/librte_cryptodev/rte_cryptodev.c           | 147
> > >> ++++++++++++++++++++++++-
> > >>>  lib/librte_cryptodev/rte_cryptodev.h           |  34 +++++-
> > >>>  lib/librte_cryptodev/rte_cryptodev_version.map |   7 ++
> > >>>  5 files changed, 191 insertions(+), 6 deletions(-)
> > >>>
> > >> [SNIP]
> > >>
> > >> Acked-by: Ray Kinsella <mdr@ashroe.eu>

Re: [dpdk-dev] [PATCH v5 2/2] cryptodev: version cryptodev info get function

[Ray Kinsella]

Seems to be an issues on my side (see below).
Everything that the ABI Compliance Checker 2.3 complains about has already been reported and suppressed in libabigail.ignore.

Suggest you use libabigail going forward. 


Oddly enough

Fedora 31 / ABI Compliance Checker 2.3
[root@xyz abi-check]# abi-compliance-checker -l librte_cryptodev.so -old 24cd1b529/librte_cryptodev.so.dump -new 26c1ec175/librte_cryptodev.so.dumpPreparing, please wait ...
Comparing ABIs ...
Comparing APIs ...
Creating compatibility report ...
Binary compatibility: 100%
Source compatibility: 100%
Total binary compatibility problems: 0, warnings: 0
Total source compatibility problems: 0, warnings: 0
Report: compat_reports/librte_cryptodev.so/24cd1b529_to_26c1ec175/compat_report.html

Ubuntu 18.04/ ABI Compliance Checker 2.2

root@abc:/build/dpdk-next-crypto/abi-check# abi-compliance-checker -l librte_cryptodev.so -old 6ef23d92d/librte_cryptodev.so.dump -new 6488cc1cf/librte_cryptodev.so.dump
Preparing, please wait ...
Comparing ABIs ...
Comparing APIs ...
Creating compatibility report ...
Binary compatibility: 99.4%
Source compatibility: 100%
Total binary compatibility problems: 1, warnings: 1
Total source compatibility problems: 0, warnings: 0
Report: compat_reports/librte_cryptodev.so/6ef23d92d_to_6488cc1cf/compat_report.html

Ray K

On 11/05/2020 09:18, Akhil Goyal wrote:
> Hi Ray,
> 
> Previously, I only ran the script for the 2 patches.
> 
> ./devtools/validate-abi.sh <commit id previous to these two patches> HEAD
> 
> However when I run for v20.02 and HEAD, the list is quite big. I believe most of them are either experimental or internal PMD. But cryptodev is still there.
> 
> NOTICE: abi-compliance-checker returned 1
> NOTICE: ABI may be incompatible, check reports/logs for details.
> NOTICE: Incompatible list:  librte_bbdev.so librte_common_iavf.so librte_common_octeontx2.so librte_cryptodev.so librte_eal.so librte_efd.so librte_eventdev.so librte_hash.so librte_ipsec.so librte_meter.so librte_pdump.so librte_pmd_crypto_scheduler.so librte_pmd_dpaa2_sec.so librte_pmd_dpaa_sec.so librte_pmd_ring.so librte_ring.so librte_vhost.so
> 
> Regards,
> Akhil
> 
>> -----Original Message-----
>> From: Ray Kinsella <mdr@ashroe.eu>
>> Sent: Monday, May 11, 2020 1:18 PM
>> To: Akhil Goyal <akhil.goyal@nxp.com>; Arek Kusztal
>> <arkadiuszx.kusztal@intel.com>; dev@dpdk.org
>> Cc: fiona.trahe@intel.com; ray.kinsella@intel.com; bruce.richardson@intel.com
>> Subject: Re: [dpdk-dev] [PATCH v5 2/2] cryptodev: version cryptodev info get
>> function
>>
>> Hi Akhil,
>>
>> So 1st thing is that this that validate-abi uses "ABI Compliance Checker",
>> which does not use libabigail.ignore.
>>
>> So you will end up with different results compared to using libabigail as follows:
>>
>> DPDK_ABI_REF_DIR=<some absolute path>
>> DPDK_ABI_REF_VERSION=v20.02 ./devtools/test-meson-builds.sh
>>
>> I did check with the "ABI Compliance Checker" (I like this tool also), however I
>> got the following
>>
>> NOTICE: No error detected, ABI is compatible.
>> INFO: Logs are in /root/src/dpdk/abi-check/abi-check.log
>> INFO: HTML reports are in /root/src/dpdk/abi-check/compat_reports directory
>>
>> What references did you use with validate-abi.sh (I used v20.02 and HEAD).
>>
>> Ray K
>>
>> On 09/05/2020 22:11, Akhil Goyal wrote:
>>> Hi Ray/Arek,
>>>
>>> I still see Incompatible cryptodev even after update in the abignore list.
>>> I checked it with ./devtools/validate-abi.sh
>>> NOTICE: ABI may be incompatible, check reports/logs for details.
>>> NOTICE: Incompatible list:  librte_cryptodev.so
>>>
>>> Did I miss something?
>>>
>>>
>>>>
>>>> On 07/05/2020 11:57, Arek Kusztal wrote:
>>>>> This patch adds versioned function rte_cryptodev_info_get()
>>>>> to prevent some issues with ABI policy.
>>>>> Node v21 works in same way as before, returning driver capabilities
>>>>> directly to the API caller. These capabilities may include new elements
>>>>> not part of the v20 ABI.
>>>>> Node v20 function maintains compatibility with v20 ABI releases
>>>>> by stripping out elements not supported in v20 ABI. Because
>>>>> rte_cryptodev_info_get is called by other API functions,
>>>>> rte_cryptodev_sym_capability_get function is versioned the same way.
>>>>>
>>>>> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
>>>>> ---
>>>>> v2:
>>>>> - changed version numbers of symbols to 20.0.2
>>>>> v3:
>>>>> - added v2/v3 informations
>>>>> - changed version numbers of symbols to 21
>>>>> v4:
>>>>> - fixed clang build by movind binding default symbol
>>>>> - implemented mailing list comments
>>>>> - added abidiff tool suppression entries
>>>>> v5:
>>>>> - fixed meson build
>>>>>
>>>>>  devtools/libabigail.abignore                   |   8 ++
>>>>>  lib/librte_cryptodev/meson.build               |   1 +
>>>>>  lib/librte_cryptodev/rte_cryptodev.c           | 147
>>>> ++++++++++++++++++++++++-
>>>>>  lib/librte_cryptodev/rte_cryptodev.h           |  34 +++++-
>>>>>  lib/librte_cryptodev/rte_cryptodev_version.map |   7 ++
>>>>>  5 files changed, 191 insertions(+), 6 deletions(-)
>>>>>
>>>> [SNIP]
>>>>
>>>> Acked-by: Ray Kinsella <mdr@ashroe.eu>

Re: [dpdk-dev] [PATCH v5 2/2] cryptodev: version cryptodev info get function

[Trahe, Fiona]

> -----Original Message-----
> From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Sent: Thursday, May 7, 2020 11:57 AM
> To: dev@dpdk.org
> Cc: Trahe, Fiona <fiona.trahe@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> akhil.goyal@nxp.com; Richardson, Bruce <bruce.richardson@intel.com>; Kusztal, ArkadiuszX
> <arkadiuszx.kusztal@intel.com>
> Subject: [PATCH v5 2/2] cryptodev: version cryptodev info get function
> 
> This patch adds versioned function rte_cryptodev_info_get()
> to prevent some issues with ABI policy.
> Node v21 works in same way as before, returning driver capabilities
> directly to the API caller. These capabilities may include new elements
> not part of the v20 ABI.
> Node v20 function maintains compatibility with v20 ABI releases
> by stripping out elements not supported in v20 ABI. Because
> rte_cryptodev_info_get is called by other API functions,
> rte_cryptodev_sym_capability_get function is versioned the same way.
> 
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
Acked-by: Fiona Trahe <fiona.trahe@intel.com>