Maybe I'm not clear enough. What I don't understand (and don't want to see), is specific functions for qat, ccp, nitrox or dpaa. The test should not care about the driver name.
20/10/2021 14:43, Zhang, Roy Fan: > Hi Thomas, > > The raw data path API tests takes advantage of existing cryptodev unit test > cases with one difference: > - in cryptodev sym crypto unit tests, all data is described by both rte_mbufs > and rte_crypto_ops. > - in raw data path API tests, the same data is converted from mbufs and crypto > ops into rte_crypto_sym_vec to test. > > However for each test case we can only use either crypto op way or raw data > path API way to run a test. To distinguish which way to use there is a global > flag > set by test command. If you want to use crypto op way to test all cases you > use one command, otherwise with other command. > > What complicated things is, cryptodev unit test needs to prepare the data > for every test. Once the test is finished the data is either encrypted or > decrypted and cannot be reused immediately. > > Using only the device capability flag to cover both crypto op tests and raw > data > path api tests in the same test function means each and every test function in > test_cryptodev.c needs to be expanded by ~30% as all data needs to be > re-prepared again for each test type. Also for the PMDs that do not support > this > test type will be shown 100% more bypassed tests in the test result briefing. > > That's the reason to have this global knob so each test function only have to > act > slight differently between crypto op test and raw data path API test. > > Regards, > Fan > > > -----Original Message----- > > From: Thomas Monjalon <tho...@monjalon.net> > > Sent: Wednesday, October 20, 2021 1:14 PM > > To: Zhang, Roy Fan <roy.fan.zh...@intel.com>; Gagandeep Singh > > <g.si...@nxp.com>; Hemant Agrawal <hemant.agra...@nxp.com>; Akhil > > Goyal <gak...@marvell.com> > > Cc: dev@dpdk.org; Ananyev, Konstantin <konstantin.anan...@intel.com>; > > acon...@redhat.com; david.march...@redhat.com > > Subject: Re: [EXT] Re: [dpdk-dev] [PATCH v5 14/15] test/crypto: add raw API > > test for dpaax > > > > 20/10/2021 11:32, Akhil Goyal: > > > > 20/10/2021 11:15, Akhil Goyal: > > > > > > 17/10/2021 18:16, Hemant Agrawal: > > > > > > > This patch add support for raw API tests for > > > > > > > dpaa_sec and dpaa2_sec platforms. > > > > > > > > > > > > Why do we have tests specific to some drivers? > > > > > > Is there a plan to remove them? > > > > > > > > > > > > > > > > The testsuites are common and there is no driver specific test. > > > > > The test command is different for each of the PMD, > > > > > that is why it is registered for each PMD. > > > > > For Raw data path APIs, all of the testsuite is run with a global > > > > > flag set. > > > > > Currently only 3 PMDs support raw APIs, we can get rid of this global > > flag in > > > > future if more > > > > > PMDs start supporting these APIs. > > > > > > > > No there is something wrong. > > > > It shows that it is not generic enough for any app. > > > > What is missing to make the same calls no matter the driver? > > > > Do we need to add some capability flags? > > > > > > Capability flags are there for raw data path APIs but the PMD can support > > both APIs. > > > And we need to test both data paths. > > > So for this we have a global variable to enable raw data path and we > > register a new > > > Command for the PMD and enable that global flag while doing that. > > > The tests, however have the capability flags checks in place but we decide > > to enable > > > Raw APIs only when the PMD support that and that global flag is set. > > > I hope it is clear now. > > > > No sorry, it is not clear. > > How may I know that the raw API is supported in a PMD? > > If there is such info, no need for specific tests?
