Hi Andrew, Sorry the mail got missed. Please see inline. > Touching base, > > When you have time to get back to us, if you have insight on question #1 it > would > be most helpful. In the meantime we are going ahead with using a smaller > subset > of cipher and authentication algorithms. Additionally we plan on using > 10,000,000 > total operations but this is not final and can be influenced by your response > to > question #2. > > > 1. Test case reusability: If a cipher algorithm passes validation in > cipher- > only mode, can we reuse that cipher algorithm across all cipher-then-auth test > runs while varying only the authentication algorithm?
From test-crypto-perf point of view, the validation is not the point. The validation is performed using the unit test app. In some of the drivers, cipher-only and cipher-then-auth have different path altogether. I would say, treat the cases as separate cases with all supported list of algorithms. If it takes too much of time, we can stick with the commonly used algos which are supported By all PMDs. You can check https://doc.dpdk.org/guides/cryptodevs/overview.html For the list of supported algos. > > 2. Operations threshold: What is the recommended number of total > operations per test to generate statistically meaningful performance metrics? > We > are starting with 30,000,000 total operations per run of the app. since test > execution time is always a concern and we may run dpdk-crypto-perf many times > with a broad matrix of ciphers/algorithms based on your response to question > #1, > we are curious if there are tests where the total-operations argument can be > reduced For Symmetric algos, 10 million is good and would be completed fast. But for Asymmetric, 100K (or 10K for some cases.)would be good enough.
