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

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 devic

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

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_destr

Re: [dpdk-dev] 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 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 ma

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

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

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

Hi Everyone, 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