[v5,14/15] test/crypto: add raw API test for dpaax
Checks
Commit Message
This patch add support for raw API tests for
dpaa_sec and dpaa2_sec platforms.
Signed-off-by: Gagandeep Singh <g.singh@nxp.com>
Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
---
app/test/test_cryptodev.c | 116 +++++++++++++++++++++++++++++++++++---
1 file changed, 109 insertions(+), 7 deletions(-)
Comments
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?
> +REGISTER_TEST_COMMAND(cryptodev_dpaa2_sec_raw_api_autotest,
> + test_cryptodev_dpaa2_sec_raw_api);
> +REGISTER_TEST_COMMAND(cryptodev_dpaa_sec_raw_api_autotest,
> + test_cryptodev_dpaa_sec_raw_api);
> REGISTER_TEST_COMMAND(cryptodev_qat_raw_api_autotest,
> test_cryptodev_qat_raw_api);
> REGISTER_TEST_COMMAND(cryptodev_qat_autotest, test_cryptodev_qat);
> 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.
> > +REGISTER_TEST_COMMAND(cryptodev_dpaa2_sec_raw_api_autotest,
> > + test_cryptodev_dpaa2_sec_raw_api);
> > +REGISTER_TEST_COMMAND(cryptodev_dpaa_sec_raw_api_autotest,
> > + test_cryptodev_dpaa_sec_raw_api);
> > REGISTER_TEST_COMMAND(cryptodev_qat_raw_api_autotest,
> > test_cryptodev_qat_raw_api);
> > REGISTER_TEST_COMMAND(cryptodev_qat_autotest,
> test_cryptodev_qat);
>
>
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?
>
> 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.
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?
> 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?
>
RTE_CRYPTODEV_FF_SYM_RAW_DP is there to check if raw data path is supported.
But how can we test both raw APIs as well as normal crypto_op ones in the same app?
For that a global variable is there in app which allow/disallow all of the test cases.
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 <thomas@monjalon.net>
> Sent: Wednesday, October 20, 2021 1:14 PM
> To: Zhang, Roy Fan <roy.fan.zhang@intel.com>; Gagandeep Singh
> <g.singh@nxp.com>; Hemant Agrawal <hemant.agrawal@nxp.com>; Akhil
> Goyal <gakhil@marvell.com>
> Cc: dev@dpdk.org; Ananyev, Konstantin <konstantin.ananyev@intel.com>;
> aconole@redhat.com; david.marchand@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?
>
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 <thomas@monjalon.net>
> > Sent: Wednesday, October 20, 2021 1:14 PM
> > To: Zhang, Roy Fan <roy.fan.zhang@intel.com>; Gagandeep Singh
> > <g.singh@nxp.com>; Hemant Agrawal <hemant.agrawal@nxp.com>; Akhil
> > Goyal <gakhil@marvell.com>
> > Cc: dev@dpdk.org; Ananyev, Konstantin <konstantin.ananyev@intel.com>;
> > aconole@redhat.com; david.marchand@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?
@@ -186,11 +186,11 @@ process_sym_raw_dp_op(uint8_t dev_id, uint16_t qp_id,
{
struct rte_crypto_sym_op *sop = op->sym;
struct rte_crypto_op *ret_op = NULL;
- struct rte_crypto_vec data_vec[UINT8_MAX];
+ struct rte_crypto_vec data_vec[UINT8_MAX], dest_data_vec[UINT8_MAX];
struct rte_crypto_va_iova_ptr cipher_iv, digest, aad_auth_iv;
union rte_crypto_sym_ofs ofs;
struct rte_crypto_sym_vec vec;
- struct rte_crypto_sgl sgl;
+ struct rte_crypto_sgl sgl, dest_sgl;
uint32_t max_len;
union rte_cryptodev_session_ctx sess;
uint32_t count = 0;
@@ -326,6 +326,19 @@ process_sym_raw_dp_op(uint8_t dev_id, uint16_t qp_id,
}
sgl.num = n;
+ /* Out of place */
+ if (sop->m_dst != NULL) {
+ dest_sgl.vec = dest_data_vec;
+ vec.dest_sgl = &dest_sgl;
+ n = rte_crypto_mbuf_to_vec(sop->m_dst, 0, max_len,
+ dest_data_vec, RTE_DIM(dest_data_vec));
+ if (n < 0 || n > sop->m_dst->nb_segs) {
+ op->status = RTE_CRYPTO_OP_STATUS_ERROR;
+ goto exit;
+ }
+ dest_sgl.num = n;
+ } else
+ vec.dest_sgl = NULL;
if (rte_cryptodev_raw_enqueue_burst(ctx, &vec, ofs, (void **)&op,
&enqueue_status) < 1) {
@@ -8381,10 +8394,21 @@ test_pdcp_proto_SGL(int i, int oop,
int to_trn_tbl[16];
int segs = 1;
unsigned int trn_data = 0;
+ struct rte_cryptodev_info dev_info;
+ uint64_t feat_flags;
struct rte_security_ctx *ctx = (struct rte_security_ctx *)
rte_cryptodev_get_sec_ctx(
ts_params->valid_devs[0]);
+ struct rte_mbuf *temp_mbuf;
+
+ rte_cryptodev_info_get(ts_params->valid_devs[0], &dev_info);
+ feat_flags = dev_info.feature_flags;
+ if ((global_api_test_type == CRYPTODEV_RAW_API_TEST) &&
+ (!(feat_flags & RTE_CRYPTODEV_FF_SYM_RAW_DP))) {
+ printf("Device does not support RAW data-path APIs.\n");
+ return -ENOTSUP;
+ }
/* Verify the capabilities */
struct rte_security_capability_idx sec_cap_idx;
@@ -8568,8 +8592,23 @@ test_pdcp_proto_SGL(int i, int oop,
ut_params->op->sym->m_dst = ut_params->obuf;
/* Process crypto operation */
- if (process_crypto_request(ts_params->valid_devs[0], ut_params->op)
- == NULL) {
+ temp_mbuf = ut_params->op->sym->m_src;
+ if (global_api_test_type == CRYPTODEV_RAW_API_TEST) {
+ /* filling lengths */
+ while (temp_mbuf) {
+ ut_params->op->sym->cipher.data.length
+ += temp_mbuf->pkt_len;
+ ut_params->op->sym->auth.data.length
+ += temp_mbuf->pkt_len;
+ temp_mbuf = temp_mbuf->next;
+ }
+ process_sym_raw_dp_op(ts_params->valid_devs[0], 0,
+ ut_params->op, 1, 1, 0, 0);
+ } else {
+ ut_params->op = process_crypto_request(ts_params->valid_devs[0],
+ ut_params->op);
+ }
+ if (ut_params->op == NULL) {
printf("TestCase %s()-%d line %d failed %s: ",
__func__, i, __LINE__,
"failed to process sym crypto op");
@@ -10450,6 +10489,7 @@ test_authenticated_encryption_oop(const struct aead_test_data *tdata)
int retval;
uint8_t *ciphertext, *auth_tag;
uint16_t plaintext_pad_len;
+ struct rte_cryptodev_info dev_info;
/* Verify the capabilities */
struct rte_cryptodev_sym_capability_idx cap_idx;
@@ -10459,7 +10499,11 @@ test_authenticated_encryption_oop(const struct aead_test_data *tdata)
&cap_idx) == NULL)
return TEST_SKIPPED;
- if (global_api_test_type == CRYPTODEV_RAW_API_TEST)
+ rte_cryptodev_info_get(ts_params->valid_devs[0], &dev_info);
+ uint64_t feat_flags = dev_info.feature_flags;
+
+ if ((global_api_test_type == CRYPTODEV_RAW_API_TEST) &&
+ (!(feat_flags & RTE_CRYPTODEV_FF_SYM_RAW_DP)))
return TEST_SKIPPED;
/* not supported with CPU crypto */
@@ -10496,7 +10540,11 @@ test_authenticated_encryption_oop(const struct aead_test_data *tdata)
ut_params->op->sym->m_dst = ut_params->obuf;
/* Process crypto operation */
- TEST_ASSERT_NOT_NULL(process_crypto_request(ts_params->valid_devs[0],
+ if (global_api_test_type == CRYPTODEV_RAW_API_TEST)
+ process_sym_raw_dp_op(ts_params->valid_devs[0], 0,
+ ut_params->op, 0, 0, 0, 0);
+ else
+ TEST_ASSERT_NOT_NULL(process_crypto_request(ts_params->valid_devs[0],
ut_params->op), "failed to process sym crypto op");
TEST_ASSERT_EQUAL(ut_params->op->status, RTE_CRYPTO_OP_STATUS_SUCCESS,
@@ -10542,6 +10590,10 @@ test_authenticated_decryption_oop(const struct aead_test_data *tdata)
int retval;
uint8_t *plaintext;
+ struct rte_cryptodev_info dev_info;
+
+ rte_cryptodev_info_get(ts_params->valid_devs[0], &dev_info);
+ uint64_t feat_flags = dev_info.feature_flags;
/* Verify the capabilities */
struct rte_cryptodev_sym_capability_idx cap_idx;
@@ -10556,6 +10608,12 @@ test_authenticated_decryption_oop(const struct aead_test_data *tdata)
global_api_test_type == CRYPTODEV_RAW_API_TEST)
return TEST_SKIPPED;
+ if ((global_api_test_type == CRYPTODEV_RAW_API_TEST) &&
+ (!(feat_flags & RTE_CRYPTODEV_FF_SYM_RAW_DP))) {
+ printf("Device does not support RAW data-path APIs.\n");
+ return TEST_SKIPPED;
+ }
+
/* Create AEAD session */
retval = create_aead_session(ts_params->valid_devs[0],
tdata->algo,
@@ -10586,7 +10644,11 @@ test_authenticated_decryption_oop(const struct aead_test_data *tdata)
ut_params->op->sym->m_dst = ut_params->obuf;
/* Process crypto operation */
- TEST_ASSERT_NOT_NULL(process_crypto_request(ts_params->valid_devs[0],
+ if (global_api_test_type == CRYPTODEV_RAW_API_TEST)
+ process_sym_raw_dp_op(ts_params->valid_devs[0], 0,
+ ut_params->op, 0, 0, 0, 0);
+ else
+ TEST_ASSERT_NOT_NULL(process_crypto_request(ts_params->valid_devs[0],
ut_params->op), "failed to process sym crypto op");
TEST_ASSERT_EQUAL(ut_params->op->status, RTE_CRYPTO_OP_STATUS_SUCCESS,
@@ -15434,6 +15496,46 @@ test_cryptodev_cn10k(void)
return run_cryptodev_testsuite(RTE_STR(CRYPTODEV_NAME_CN10K_PMD));
}
+static int
+test_cryptodev_dpaa2_sec_raw_api(void)
+{
+ static const char *pmd_name = RTE_STR(CRYPTODEV_NAME_DPAA2_SEC_PMD);
+ int ret;
+
+ ret = require_feature_flag(pmd_name, RTE_CRYPTODEV_FF_SYM_RAW_DP,
+ "RAW API");
+ if (ret)
+ return ret;
+
+ global_api_test_type = CRYPTODEV_RAW_API_TEST;
+ ret = run_cryptodev_testsuite(pmd_name);
+ global_api_test_type = CRYPTODEV_API_TEST;
+
+ return ret;
+}
+
+static int
+test_cryptodev_dpaa_sec_raw_api(void)
+{
+ static const char *pmd_name = RTE_STR(CRYPTODEV_NAME_DPAA2_SEC_PMD);
+ int ret;
+
+ ret = require_feature_flag(pmd_name, RTE_CRYPTODEV_FF_SYM_RAW_DP,
+ "RAW API");
+ if (ret)
+ return ret;
+
+ global_api_test_type = CRYPTODEV_RAW_API_TEST;
+ ret = run_cryptodev_testsuite(pmd_name);
+ global_api_test_type = CRYPTODEV_API_TEST;
+
+ return ret;
+}
+
+REGISTER_TEST_COMMAND(cryptodev_dpaa2_sec_raw_api_autotest,
+ test_cryptodev_dpaa2_sec_raw_api);
+REGISTER_TEST_COMMAND(cryptodev_dpaa_sec_raw_api_autotest,
+ test_cryptodev_dpaa_sec_raw_api);
REGISTER_TEST_COMMAND(cryptodev_qat_raw_api_autotest,
test_cryptodev_qat_raw_api);
REGISTER_TEST_COMMAND(cryptodev_qat_autotest, test_cryptodev_qat);