On Wed, 3 Sept 2025 at 11:27, Burakov, Anatoly <[email protected]> wrote: > > On 7/19/2025 5:32 PM, Yang Ming wrote: > > When a secondary process tries to release a queue pair (QP) that > > does not belong to it, error logs occur: > > CRYPTODEV: ipsec_mb_ipc_request() line 373: Unable to release > > qp_id=0 > > EAL: Message data is too long > > EAL: Fail to handle message: ipsec_mb_mp_msg > > EAL: Fail to recv reply for request /tmp/dpdk/l2hi/mp_socket: > > ipsec_mb_mp_msg > > > > From the code path, cryptodev->data is allocated in the primary > > via rte_cryptodev_data_alloc() (inside > > ipsec_mb_create-->rte_cryptodev_pmd_create > > -->rte_cryptodev_pmd_allocate-->rte_cryptodev_data_alloc). > > This memory is placed in a shared memzone > > (rte_cryptodev_data_%u), so both primary and secondary processes > > reference the same cryptodev->data, including nb_queue_pairs and > > queue_pairs[]. > > > > As a result, when the secondary process exits, ipsec_mb_remove() > > is called (inside > > rte_eal_cleanup-->eal_bus_cleanup-->vdev_cleanup > > -->rte_vdev_driver-->ipsec_mb_remove-->ipsec_mb_qp_release > > -->ipsec_mb_secondary_qp_op) and it loops through all queue > > pairs using: > > for (qp_id = 0; qp_id < cryptodev->data->nb_queue_pairs; qp_id++) > > ipsec_mb_qp_release(cryptodev, qp_id); > > > > This causes the secondary to attempt releasing queue pairs it > > doesn't own, triggering the error logs mentioned above. > > > > This patch ensures that a secondary process only frees a QP if > > it actually owns it, preventing conflicts and resolving the > > issue. > > > > Fixes: b35848bc01f6 ("crypto/ipsec_mb: add multi-process IPC request > > handler") > > Cc: [email protected] > > Cc: [email protected] > > > > Signed-off-by: Yang Ming <[email protected]> > Acked-by: Anatoly Burakov <[email protected]>
Series applied, thanks. -- David Marchand
