Hi Ciara, Please see inline.
Thanks, Anoob > > External Email > > ---------------------------------------------------------------------- > Hi Anoob, > > >-----Original Message----- > >From: Anoob Joseph <[email protected]> > >Sent: Friday 3 September 2021 05:47 > >To: Akhil Goyal <[email protected]>; Doherty, Declan > ><[email protected]>; Zhang, Roy Fan <[email protected]>; > >Ananyev, Konstantin <[email protected]> > >Cc: Anoob Joseph <[email protected]>; Jerin Jacob > ><[email protected]>; Archana Muniganti <[email protected]>; > >Tejasree Kondoj <[email protected]>; Hemant Agrawal > ><[email protected]>; Nicolau, Radu <[email protected]>; > >Power, Ciara <[email protected]>; Gagandeep Singh > ><[email protected]>; [email protected] > >Subject: [PATCH v3 2/5] test/crypto: add combined mode tests > > > >Add framework to test IPsec features with all supported combinations of > ciphers. > > > >Signed-off-by: Anoob Joseph <[email protected]> > >Signed-off-by: Tejasree Kondoj <[email protected]> > >--- > <snip> > > >+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 > > >+ 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, > >+ 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>
