|SUCCESS| [2/2] crypto/ipsec_mb: remove ZUC and SNOW 3G drivers from x86 build
dpdklab at iol.unh.edu
dpdklab at iol.unh.edu
Wed Jun 3 20:19:20 CEST 2026
Test-Label: ai-code-review
Test-Status: SUCCESS
https://dpdk.org/patch/164899
_AI Code Review_
=== Patch Review: series.patch (via Claude) ===
Review date: 2026-06-03
Commit: (git sha needed - not provided in patch file)
Author: Radu Nicolau <radu.nicolau at intel.com>
Subject: [PATCH 1/2] crypto/ipsec_mb: remove chacha-poly and kasumi drivers
The Chacha20-poly1305 and KASUMI drivers were just wrappers around the
main AESNI_MB driver, hence redundant and removed.
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 72fc12b1f2..567d1c872e 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1234,14 +1234,10 @@ M: Pablo de Lara <pablo.de.lara.guarch at intel.com>
> F: drivers/crypto/ipsec_mb/
> F: doc/guides/cryptodevs/aesni_gcm.rst
> F: doc/guides/cryptodevs/aesni_mb.rst
> -F: doc/guides/cryptodevs/chacha20_poly1305.rst
> -F: doc/guides/cryptodevs/kasumi.rst
[ ... ]
> diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c
> index a60983c6b7..b908f10317 100644
> --- a/app/test/test_cryptodev.c
> +++ b/app/test/test_cryptodev.c
> @@ -20602,17 +20602,6 @@ test_cryptodev_cpu_aesni_mb(void)
> return rc;
> }
>
> -static int
> -test_cryptodev_chacha_poly_mb(void)
> -{
> - int32_t rc;
> - enum rte_security_session_action_type at = gbl_action_type;
> - rc = run_cryptodev_testsuite(
> - RTE_STR(CRYPTODEV_NAME_CHACHA20_POLY1305_PMD));
> - gbl_action_type = at;
> - return rc;
> -}
[ ... ]
> diff --git a/drivers/crypto/ipsec_mb/ipsec_mb_private.h b/drivers/crypto/ipsec_mb/ipsec_mb_private.h
> index 025767cfce..9712bf5b4c 100644
> --- a/drivers/crypto/ipsec_mb/ipsec_mb_private.h
> +++ b/drivers/crypto/ipsec_mb/ipsec_mb_private.h
> @@ -45,18 +45,12 @@ extern RTE_DEFINE_PER_LCORE(IMB_MGR *, mb_mgr);
> #define CRYPTODEV_NAME_AESNI_GCM_PMD crypto_aesni_gcm
> /**< IPSEC Multi buffer PMD aesni_gcm device name */
>
> -#define CRYPTODEV_NAME_KASUMI_PMD crypto_kasumi
> -/**< IPSEC Multi buffer PMD kasumi device name */
> -
> #define CRYPTODEV_NAME_SNOW3G_PMD crypto_snow3g
> /**< IPSEC Multi buffer PMD snow3g device name */
>
> #define CRYPTODEV_NAME_ZUC_PMD crypto_zuc
> /**< IPSEC Multi buffer PMD zuc device name */
>
> -#define CRYPTODEV_NAME_CHACHA20_POLY1305_PMD crypto_chacha20_poly1305
> -/**< IPSEC Multi buffer PMD chacha20_poly1305 device name */
> -
> /** PMD LOGTYPE DRIVER, common to all PMDs */
> extern int ipsec_mb_logtype_driver;
> #define RTE_LOGTYPE_IPSEC_MB ipsec_mb_logtype_driver
> @@ -68,10 +62,8 @@ extern int ipsec_mb_logtype_driver;
> enum ipsec_mb_pmd_types {
> IPSEC_MB_PMD_TYPE_AESNI_MB = 0,
> IPSEC_MB_PMD_TYPE_AESNI_GCM,
> - IPSEC_MB_PMD_TYPE_KASUMI,
> IPSEC_MB_PMD_TYPE_SNOW3G,
> IPSEC_MB_PMD_TYPE_ZUC,
> - IPSEC_MB_PMD_TYPE_CHACHA20_POLY1305,
> IPSEC_MB_N_PMD_TYPES
> };
In ipsec_mb_get_driver_id(), does the removal of KASUMI and
CHACHA20_POLY1305 cases leave any callers that could call this function
with those enum values? If external code was using these PMD types and
calling this function, does this removal introduce a silent failure
where the default case returns 0 instead of handling an error condition?
> @@ -92,10 +84,8 @@ enum ipsec_mb_operation {
>
> extern uint8_t pmd_driver_id_aesni_mb;
> extern uint8_t pmd_driver_id_aesni_gcm;
> -extern uint8_t pmd_driver_id_kasumi;
> extern uint8_t pmd_driver_id_snow3g;
> extern uint8_t pmd_driver_id_zuc;
> -extern uint8_t pmd_driver_id_chacha20_poly1305;
>
> /** Helper function. Gets driver ID based on PMD type */
> static __rte_always_inline uint8_t
> @@ -106,14 +96,10 @@ ipsec_mb_get_driver_id(enum ipsec_mb_pmd_types pmd_type)
> return pmd_driver_id_aesni_mb;
> case IPSEC_MB_PMD_TYPE_AESNI_GCM:
> return pmd_driver_id_aesni_gcm;
> - case IPSEC_MB_PMD_TYPE_KASUMI:
> - return pmd_driver_id_kasumi;
> case IPSEC_MB_PMD_TYPE_SNOW3G:
> return pmd_driver_id_snow3g;
> case IPSEC_MB_PMD_TYPE_ZUC:
> return pmd_driver_id_zuc;
> - case IPSEC_MB_PMD_TYPE_CHACHA20_POLY1305:
> - return pmd_driver_id_chacha20_poly1305;
> default:
> break;
> }
[ ... ]
> diff --git a/drivers/crypto/ipsec_mb/pmd_chacha_poly.c b/drivers/crypto/ipsec_mb/pmd_chacha_poly.c
> deleted file mode 100644
> index 24488d4921..0000000000
> --- a/drivers/crypto/ipsec_mb/pmd_chacha_poly.c
> +++ /dev/null
[ ... ]
Commit: (git sha needed - not provided in patch file)
Author: Radu Nicolau <radu.nicolau at intel.com>
Subject: [PATCH 2/2] crypto/ipsec_mb: remove ZUC and SNOW 3G drivers from x86
build
The ZUC and SNOW 3G crypto drivers are using APIs that are now deprecated
in the Intel IPsec Multi-Buffer library.
> diff --git a/doc/guides/cryptodevs/aesni_mb.rst b/doc/guides/cryptodevs/aesni_mb.rst
> index 9d886657f2..5efbadb8d1 100644
> --- a/doc/guides/cryptodevs/aesni_mb.rst
> +++ b/doc/guides/cryptodevs/aesni_mb.rst
> @@ -82,7 +82,7 @@ Limitations
> DOCSIS security protocol.
>
> AESNI MB PMD selection over SNOW3G/ZUC PMDs
> ---------------------------------------------------
> +-------------------------------------------
[ ... ]
> diff --git a/drivers/crypto/ipsec_mb/ipsec_mb_private.h b/drivers/crypto/ipsec_mb/ipsec_mb_private.h
> index 9712bf5b4c..fc7d6f5f06 100644
> --- a/drivers/crypto/ipsec_mb/ipsec_mb_private.h
> +++ b/drivers/crypto/ipsec_mb/ipsec_mb_private.h
> @@ -45,11 +45,13 @@ extern RTE_DEFINE_PER_LCORE(IMB_MGR *, mb_mgr);
> #define CRYPTODEV_NAME_AESNI_GCM_PMD crypto_aesni_gcm
> /**< IPSEC Multi buffer PMD aesni_gcm device name */
>
> +#if defined(RTE_ARCH_ARM)
> #define CRYPTODEV_NAME_SNOW3G_PMD crypto_snow3g
> /**< IPSEC Multi buffer PMD snow3g device name */
>
> #define CRYPTODEV_NAME_ZUC_PMD crypto_zuc
> /**< IPSEC Multi buffer PMD zuc device name */
> +#endif
In ipsec_mb_private.h, does this conditional compilation break any
existing application or test code that references
CRYPTODEV_NAME_SNOW3G_PMD or CRYPTODEV_NAME_ZUC_PMD on x86 platforms?
Will the application compilation fail with undefined reference errors if
these macros are used on x86?
> /** PMD LOGTYPE DRIVER, common to all PMDs */
> extern int ipsec_mb_logtype_driver;
> @@ -62,8 +64,10 @@ extern int ipsec_mb_logtype_driver;
> enum ipsec_mb_pmd_types {
> IPSEC_MB_PMD_TYPE_AESNI_MB = 0,
> IPSEC_MB_PMD_TYPE_AESNI_GCM,
> +#if defined(RTE_ARCH_ARM)
> IPSEC_MB_PMD_TYPE_SNOW3G,
> IPSEC_MB_PMD_TYPE_ZUC,
> +#endif
> IPSEC_MB_N_PMD_TYPES
> };
Does this conditional enumeration cause the IPSEC_MB_N_PMD_TYPES value
to differ between ARM and x86 builds? Could this break any existing code
that relies on this value for array sizing or loop bounds that might be
shared between architectures?
> /** PMD operation */
> @@ -96,10 +100,12 @@ ipsec_mb_get_driver_id(enum ipsec_mb_pmd_types pmd_type)
> return pmd_driver_id_aesni_mb;
> case IPSEC_MB_PMD_TYPE_AESNI_GCM:
> return pmd_driver_id_aesni_gcm;
> +#if defined(RTE_ARCH_ARM)
> case IPSEC_MB_PMD_TYPE_SNOW3G:
> return pmd_driver_id_snow3g;
> case IPSEC_MB_PMD_TYPE_ZUC:
> return pmd_driver_id_zuc;
> +#endif
> default:
> break;
> }
When ipsec_mb_get_driver_id() is called on x86 with
IPSEC_MB_PMD_TYPE_SNOW3G or IPSEC_MB_PMD_TYPE_ZUC (if these enum values
are still reachable on x86), does the function now silently fall through
to the default case? Are there existing callers that might encounter
this scenario?
> diff --git a/drivers/crypto/ipsec_mb/meson.build b/drivers/crypto/ipsec_mb/meson.build
> index 6c5e4e2259..eb2085725b 100644
> --- a/drivers/crypto/ipsec_mb/meson.build
> +++ b/drivers/crypto/ipsec_mb/meson.build
> @@ -42,8 +42,13 @@ sources = files(
> 'ipsec_mb_ops.c',
> 'pmd_aesni_mb.c',
> 'pmd_aesni_gcm.c',
> - 'pmd_snow3g.c',
> - 'pmd_zuc.c',
> )
> +# PMDs supported only on ARM build
> +if arch_subdir == 'arm'
> + sources += files(
> + 'pmd_snow3g.c',
> + 'pmd_zuc.c',
> + )
> +endif
> deps += ['bus_vdev', 'net', 'security']
> require_iova_in_mbuf = false
Does this conditional compilation in meson.build create any issues with
the extern declarations for pmd_driver_id_snow3g and pmd_driver_id_zuc
which remain unconditionally declared in ipsec_mb_private.h? Will these
variables be undefined on x86 builds, potentially causing linker errors
if any remaining code references them?
More information about the test-report
mailing list