Hi Ciara,

Please see inline.

Thanks,
Anoob

External Email

----------------------------------------------------------------------
Hi Anoob,

quoted

-----Original Message-----
From: Anoob Joseph <redacted>
Sent: Friday 3 September 2021 05:47
To: Akhil Goyal <redacted>; Doherty, Declan
[off-list ref]; Zhang, Roy Fan [off-list ref];
Ananyev, Konstantin [off-list ref]
Cc: Anoob Joseph <redacted>; Jerin Jacob
[off-list ref]; Archana Muniganti [off-list ref];
Tejasree Kondoj [off-list ref]; Hemant Agrawal
[off-list ref]; Nicolau, Radu [off-list ref];
Power, Ciara [off-list ref]; Gagandeep Singh
[off-list ref]; dev@dpdk.org
Subject: [PATCH v3 2/5] test/crypto: add combined mode tests

Add framework to test IPsec features with all supported combinations of

ciphers.

quoted

Signed-off-by: Anoob Joseph <redacted>
Signed-off-by: Tejasree Kondoj <redacted>
---

<snip>

quoted

+static int
+test_ipsec_proto_all(const struct ipsec_test_flags *flags) {
+	struct ipsec_test_data td_outb[IPSEC_TEST_PACKETS_MAX];
+	struct ipsec_test_data td_inb[IPSEC_TEST_PACKETS_MAX];
+	unsigned int i, nb_pkts = 1, pass_cnt = 0;
+	int ret;
+

Is this testcase actually running multiple testcases under the hood?
I wonder could it be suited to use a sub-testsuite structure to bring the
testcase results up to the top level, as done with cryptodev blockcipher tests.
Have you considered this approach?

[Anoob] The idea behind this framework is to test an IPsec feature (like UDP encapsulation) without tying it to any specific algorithm. So what this does is, it loops over a list of possible combinations and then runs the test for each combination. The test would be like this,

1. Do outbound processing to generate encrypted packet
2. Basic checks or validation as required for the test (for example, with UDP encapsulation, we would validate UDP hdr in the processed packet).
3. Any manipulations required (like for ICV corruption negative test)
4. Do inbound processing to get decrypted packet
5. Validate results based on the type of test (ICV corruption would give expect an error while normal tests would have the operation return original plain text packet)

It's actually the array (aead_list) and this loop which initiates the test to be run for all algos. And, since we are not having static vectors for each test case, this approach seemed more straightforward. Do you think sub-testsuite makes more sense here?
 

Thanks,
Ciara

quoted

+	for (i = 0; i < RTE_DIM(aead_list); i++) {
+		test_ipsec_td_prepare(&aead_list[i],
+				      NULL,
+				      flags,
+				      td_outb,
+				      nb_pkts);
+
+		ret = test_ipsec_proto_process(td_outb, td_inb, nb_pkts,

true,

quoted

+					       flags);
+		if (ret == TEST_SKIPPED)
+			continue;
+
+		if (ret == TEST_FAILED)
+			return TEST_FAILED;
+
+		test_ipsec_td_update(td_inb, td_outb, nb_pkts, flags);
+
+		ret = test_ipsec_proto_process(td_inb, NULL, nb_pkts, true,
+					       flags);
+		if (ret == TEST_SKIPPED)
+			continue;
+
+		if (ret == TEST_FAILED)
+			return TEST_FAILED;
+
+		if (flags->display_alg)
+			test_ipsec_display_alg(&aead_list[i], NULL);
+
+		pass_cnt++;
+	}
+
+	if (pass_cnt > 0)
+		return TEST_SUCCESS;
+	else
+		return TEST_SKIPPED;
+}
+

<snip>