Re: [dpdk-dev] Recent change to make rte_cryptodev_pmd.h internal prevents some important functionality

[Akhil Goyal <gakhil@marvell.com>]

Ahh, yes!!!
queue_pair_release is not a public API it was mentioned in the rte_cryptodev_pmd.h, and it was mentioned on top of the file NOT to use it directly in the application.

Could you please mention the use case for which this memory need to be cleared before the stop or close of the device. Or you can send the patch to introduce it and explain the requirement of the use case in patch description.

Regards,
Akhil

From: Zhang, Roy Fan <roy.fan.zhang@intel.com>
Sent: Monday, October 4, 2021 1:14 PM
To: Akhil Goyal <gakhil@marvell.com>; Luse, Paul E <paul.e.luse@intel.com>; dev@dpdk.org
Cc: matan@nvidia.com; hemant.agrawal@nxp.com
Subject: [EXT] RE: Recent change to make rte_cryptodev_pmd.h internal prevents some important functionality

External Email
________________________________
Hi Akhil,

This isn't what our concern was - our concern was rte_cryptodev_close() may not remove the memory complete as rte_cryptodev_pmd_destroy() did.
Our research result towards this was if the PMD could act more throughout to make rte_cryptodev_close() working same as rte_cryptodev_pmd_destroy().

What Paul's concern is valid: We DO NOT have a way to release a queue pair manually anymore, and releasing queue pair to me should not be blocked from public API access.
To resolve this problem we should have a public queue_pair_release() function in the cryptodev. If you are ok I can send a patch for 21.11 right away.

Regards,
Fan


From: Akhil Goyal <gakhil@marvell.com<mailto:gakhil@marvell.com>>
Sent: Monday, October 4, 2021 7:45 AM
To: Luse, Paul E <paul.e.luse@intel.com<mailto:paul.e.luse@intel.com>>; dev@dpdk.org<mailto:dev@dpdk.org>; Zhang, Roy Fan <roy.fan.zhang@intel.com<mailto:roy.fan.zhang@intel.com>>
Cc: matan@nvidia.com<mailto:matan@nvidia.com>; hemant.agrawal@nxp.com<mailto:hemant.agrawal@nxp.com>
Subject: RE: Recent change to make rte_cryptodev_pmd.h internal prevents some important functionality

Hi Paul,

Similar comment was discussed in ML for fips_validation app.
https://mails.dpdk.org/archives/dev/2021-August/217781.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__mails.dpdk.org_archives_dev_2021-2DAugust_217781.html&d=DwMF-g&c=nKjWec2b6R0mOyPaz7xtfQ&r=DnL7Si2wl_PRwpZ9TWey3eu68gBzn7DkPwuqhd6WNyo&m=eFx4r9BszjCwl-WvV9JP_HjGT3TMtUVN83UrpvyBHmU&s=jOT5qDz1QS810Yh0V9fLh-dUP-vxPn5EsoKinD7xt10&e=>

I believe Fan is working on it to fix the issue.
Fan, Could you please share the update.

Regards,
Akhil

Note: Please CC maintainers for a prompt response, or else mails can be skipped.

From: Luse, Paul E <paul.e.luse@intel.com<mailto:paul.e.luse@intel.com>>
Sent: Sunday, October 3, 2021 3:14 AM
To: dev@dpdk.org<mailto:dev@dpdk.org>
Cc: Akhil Goyal <gakhil@marvell.com<mailto:gakhil@marvell.com>>; matan@nvidia.com<mailto:matan@nvidia.com>; Zhang, Roy Fan <roy.fan.zhang@intel.com<mailto:roy.fan.zhang@intel.com>>; hemant.agrawal@nxp.com<mailto:hemant.agrawal@nxp.com>
Subject: [EXT] Recent change to make rte_cryptodev_pmd.h internal prevents some important functionality

External Email
________________________________
Hi Everyone,

I sent this last week and haven't heard back - apologize if I missed the response but if not here it is again...

We use cryptodev in SPDK and included rte_cryptodev_pmd.h so that we may release qpair memory that was allocated when we called rte_cryptodev_queue_pair_setup().  We'd do so by calling the function pointer queue_pair_release() which I believe is the prescribed way to do this.

The DPDK change in question is here: https://github.com/DPDK/dpdk/commit/af668035f7f492424b2e199f155690815944a8ca<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_DPDK_dpdk_commit_af668035f7f492424b2e199f155690815944a8ca&d=DwMF-g&c=nKjWec2b6R0mOyPaz7xtfQ&r=DnL7Si2wl_PRwpZ9TWey3eu68gBzn7DkPwuqhd6WNyo&m=JtjV1tR2S7GKiUDbCzH0F3Eb5a0srzYbypWQ7frSYlM&s=KPcZHMXJD19T_7amxWdYShvis2l7nWAnfs-nJ85FVto&e=>

Question: Is there another way for us to release this memory? I've looked through the public API and nothing stands out.

Thanks
Paul