[PATCH v2 2/2] crypto/ipsec_mb: fix QP release in secondary
David Marchand
david.marchand at redhat.com
Mon May 5 17:31:10 CEST 2025
Hello,
On Thu, Apr 24, 2025 at 4:26 PM Yang Ming <ming.1.yang at nokia-sbell.com> wrote:
>
> Hi,
>
> On 2025/4/7 13:25, Yang Ming wrote:
> > From: myang <ming.1.yang at nokia-sbell.com>
> >
> > 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
> >
> > This patch ensures that a secondary process only frees a QP if
> > it actually owns it, preventing conflicts and resolving the
> > issue.
> >
> > Signed-off-by: myang <ming.1.yang at nokia-sbell.com>
> > ---
> > drivers/crypto/ipsec_mb/ipsec_mb_ops.c | 7 +++++--
> > 1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/crypto/ipsec_mb/ipsec_mb_ops.c b/drivers/crypto/ipsec_mb/ipsec_mb_ops.c
> > index 910efb1a97..50ee140ccd 100644
> > --- a/drivers/crypto/ipsec_mb/ipsec_mb_ops.c
> > +++ b/drivers/crypto/ipsec_mb/ipsec_mb_ops.c
> > @@ -138,6 +138,7 @@ int
> > ipsec_mb_qp_release(struct rte_cryptodev *dev, uint16_t qp_id)
> > {
> > struct ipsec_mb_qp *qp = dev->data->queue_pairs[qp_id];
> > + uint16_t process_id = (uint16_t)getpid();
> >
> > if (!qp)
> > return 0;
> > @@ -152,8 +153,10 @@ ipsec_mb_qp_release(struct rte_cryptodev *dev, uint16_t qp_id)
> > rte_free(qp);
> > dev->data->queue_pairs[qp_id] = NULL;
> > } else { /* secondary process */
> > - return ipsec_mb_secondary_qp_op(dev->data->dev_id, qp_id,
> > - NULL, 0, RTE_IPSEC_MB_MP_REQ_QP_FREE);
> > + if (qp->qp_used_by_pid == process_id)
> > + return ipsec_mb_secondary_qp_op(dev->data->dev_id,
> > + qp_id, NULL, 0,
> > + RTE_IPSEC_MB_MP_REQ_QP_FREE);
> > }
> > return 0;
> > }
>
> Hi Experts,
>
> Is there any chance to review and accept this patch?
Don't forget to Cc maintainers.
--
David Marchand
More information about the dev
mailing list