|SUCCESS| app/crypto-perf: support ML KEM

dpdklab at iol.unh.edu dpdklab at iol.unh.edu
Thu May 28 19:50:16 CEST 2026


Test-Label: ai-code-review
Test-Status: SUCCESS
https://dpdk.org/patch/164524

_AI Code Review_

=== Patch Review: series.patch (via Claude) ===
Review date: 2026-05-28

# Review of DPDK Patch: app/crypto-perf: support ML KEM

git sha: 20260528075853.2206573-1-psenapati at marvell.com

Author: Pratik Senapati <psenapati at marvell.com>

Subject: [PATCH] app/crypto-perf: support ML KEM

This patch adds ML-KEM512 support to the test-crypto-perf application,
including new test vectors, operation setup functions, and command-line
option handling.

```
diff --git a/app/test-crypto-perf/cperf_ops.c b/app/test-crypto-perf/cperf_ops.c
index 9297b4a3d3..806265f7bf 100644
--- a/app/test-crypto-perf/cperf_ops.c
+++ b/app/test-crypto-perf/cperf_ops.c
@@ -208,6 +208,49 @@ cperf_set_ops_asym_sm2(struct rte_crypto_op **ops,
 	}
 }
 
+static void
+cperf_set_ops_asym_mlkem(struct rte_crypto_op **ops,
+		uint32_t src_buf_offset __rte_unused,
+		uint32_t dst_buf_offset __rte_unused, uint16_t nb_ops,
+		void *sess,
+		const struct cperf_options *options,
+		const struct cperf_test_vector *test_vector __rte_unused,
+		uint16_t iv_offset __rte_unused,
+		uint32_t *imix_idx __rte_unused,
+		uint64_t *tsc_start __rte_unused)
+{
+	uint16_t i;
+
+	for (i = 0; i < nb_ops; i++) {
+		struct rte_crypto_asym_op *asym_op = ops[i]->asym;
+
+		ops[i]->status = RTE_CRYPTO_OP_STATUS_NOT_PROCESSED;
+		rte_crypto_op_attach_asym_session(ops[i], sess);
+
+		if (options->asym_op_type == RTE_CRYPTO_ASYM_OP_ENCRYPT) {
+			asym_op->mlkem.op = RTE_CRYPTO_ML_KEM_OP_ENCAP;
+			asym_op->mlkem.encap.ek.data = options->mlkem_data->ek.data;
+			asym_op->mlkem.encap.ek.length = options->mlkem_data->ek.length;
+			asym_op->mlkem.encap.cipher.data = options->mlkem_data->cipher.data;
+			asym_op->mlkem.encap.cipher.length = options->mlkem_data->cipher.length;
+			asym_op->mlkem.encap.sk.data = options->mlkem_data->sk.data;
+			asym_op->mlkem.encap.sk.length = options->mlkem_data->sk.length;
+			asym_op->mlkem.encap.message.data = options->mlkem_data->message.data;
+			asym_op->mlkem.encap.message.length = options->mlkem_data->message.length;
+		} else if (options->asym_op_type == RTE_CRYPTO_ASYM_OP_DECRYPT) {
+			asym_op->mlkem.op = RTE_CRYPTO_ML_KEM_OP_DECAP;
+			asym_op->mlkem.decap.dk.data = options->mlkem_data->dk.data;
+			asym_op->mlkem.decap.dk.length = options->mlkem_data->dk.length;
+			asym_op->mlkem.decap.cipher.data = options->mlkem_data->cipher.data;
+			asym_op->mlkem.decap.cipher.length = options->mlkem_data->cipher.length;
+			asym_op->mlkem.decap.sk.data = options->mlkem_data->sk.data;
+			asym_op->mlkem.decap.sk.length = options->mlkem_data->sk.length;
+		} else {
+			rte_panic("Unsupported ML-KEM operation type %d\n", options->asym_op_type);

In cperf_set_ops_asym_mlkem(), does this code leak memory from the
previously attached session if the asym_op_type is invalid? The session
was already attached before validation occurs.

+		}
+	}
+}
+
 
 #ifdef RTE_LIB_SECURITY
 static void

[ ... ]

@@ -1226,6 +1269,21 @@ cperf_create_session(struct rte_mempool *sess_mp,
 
 		return asym_sess;
 	}
+
+	if (options->op_type == CPERF_ASYM_MLKEM512) {
+		xform.next = NULL;
+		xform.xform_type = RTE_CRYPTO_ASYM_XFORM_ML_KEM;
+		xform.mlkem.type = RTE_CRYPTO_ML_KEM_512;
+
+		ret = rte_cryptodev_asym_session_create(dev_id, &xform, sess_mp, &asym_sess);
+		if (ret < 0) {
+			RTE_LOG(ERR, USER1, "ML-KEM Asym session create failed\n");
+			return NULL;
+		}
+		return asym_sess;
+	}
+
+

Does this code have unnecessary blank lines at the end that violate the
coding style?

[ ... ]

diff --git a/app/test-crypto-perf/cperf_options_parsing.c b/app/test-crypto-perf/cperf_options_parsing.c
index 14e731586b..34afa938c8 100644
--- a/app/test-crypto-perf/cperf_options_parsing.c
+++ b/app/test-crypto-perf/cperf_options_parsing.c

[ ... ]

@@ -1669,6 +1675,18 @@ cperf_options_check(struct cperf_options *options)
 		}
 	}
 
+	if (options->op_type == CPERF_ASYM_MLKEM512) {
+		if (options->asym_op_type == RTE_CRYPTO_ASYM_OP_ENCRYPT)
+			options->mlkem_data = &mlkem_encap_perf_data[0];
+		else if (options->asym_op_type == RTE_CRYPTO_ASYM_OP_DECRYPT)
+			options->mlkem_data = &mlkem_decap_perf_data[0];
+		else {
+			RTE_LOG(ERR, USER1,
+				"ML-KEM operations only support encrypt (encapsulate) and decrypt (decapsulate)\n");

Does this line exceed the 79 character line length limit?

+			return -EINVAL;
+		}
+	}
+

[ ... ]

diff --git a/app/test-crypto-perf/cperf_test_common.c b/app/test-crypto-perf/cperf_test_common.c
index caf429b4d9..383d4bd940 100644
--- a/app/test-crypto-perf/cperf_test_common.c
+++ b/app/test-crypto-perf/cperf_test_common.c
@@ -313,7 +313,8 @@ cperf_is_asym_test(const struct cperf_options *options)
 	    options->op_type == CPERF_ASYM_SECP384R1 ||
 	    options->op_type == CPERF_ASYM_SECP521R1 ||
 	    options->op_type == CPERF_ASYM_ED25519 ||
-	    options->op_type == CPERF_ASYM_SM2)
+	    options->op_type == CPERF_ASYM_SM2 ||
+		options->op_type == CPERF_ASYM_MLKEM512)

Does this code use a tab character for indentation where spaces are
expected? The MLKEM512 line should align with previous lines using tabs.

 		return true;
 
 	return false;

[ ... ]

diff --git a/app/test-crypto-perf/main.c b/app/test-crypto-perf/main.c
index f63e892413..2e228201ab 100644
--- a/app/test-crypto-perf/main.c
+++ b/app/test-crypto-perf/main.c

[ ... ]

@@ -515,6 +517,23 @@ cperf_verify_devices_capabilities(struct cperf_options *opts,
 			}
 		}
 
+		if (opts->op_type == CPERF_ASYM_MLKEM512) {
+			asym_cap_idx.type = RTE_CRYPTO_ASYM_XFORM_ML_KEM;
+			asym_capability = rte_cryptodev_asym_capability_get(cdev_id, &asym_cap_idx);
+			if (asym_capability == NULL)
+				return -1;
+
+			if (opts->asym_op_type == RTE_CRYPTO_ASYM_OP_ENCRYPT)
+				opts->mlkem_data = &mlkem_encap_perf_data[0];
+			else if (opts->asym_op_type == RTE_CRYPTO_ASYM_OP_DECRYPT)
+				opts->mlkem_data = &mlkem_decap_perf_data[0];
+			else {
+				RTE_LOG(ERR, USER1, "Unsupported MLKEM operation type\n");
+				return -ENOTSUP;
+			}
+
+		}

Can the mlkem_data assignment logic in
cperf_verify_devices_capabilities() be consolidated with the similar
logic in cperf_options_check() to avoid duplication?

+
 		if (opts->op_type == CPERF_AUTH_ONLY ||
 				opts->op_type == CPERF_CIPHER_THEN_AUTH ||
 				opts->op_type == CPERF_AUTH_THEN_CIPHER) {
```


More information about the test-report mailing list