From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id AC8AB46727; Mon, 12 May 2025 12:10:37 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 35CD9402C9; Mon, 12 May 2025 12:10:37 +0200 (CEST) Received: from mail-pg1-f172.google.com (mail-pg1-f172.google.com [209.85.215.172]) by mails.dpdk.org (Postfix) with ESMTP id 550674025D for ; Mon, 12 May 2025 12:10:35 +0200 (CEST) Received: by mail-pg1-f172.google.com with SMTP id 41be03b00d2f7-b1ff9b276c2so2414697a12.1 for ; Mon, 12 May 2025 03:10:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1747044634; x=1747649434; darn=dpdk.org; h=in-reply-to:from:references:to:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=XPyJ6o3OXpys9hf967nLzC11+wK2eMIoU5aWrum7yco=; b=Q2RpPDXLDHrN6/t6g3/bzTHvq5Y+O6KrgQAF2z0ACRjFr3i3pFfNdiqb9smY55E9UK wk1QrDj/P79SJypCdBamX+mAHJinAVSXEKsSB75OIghMLakbrK6eq/HMJVkX69qcsEgK sAYG+wAcxqcRRcdi4onIKRXNXUWG8WvqltBGASgnuqSKhyS8NJ1yPbP5xa66q3XZOnNT EQAb6GHPWkcQ07kJppG4HqvfdpLWvsg2DftbNw3xqCTT6edHv4KlSSiSLfXz5SGDvFEf XhPFW5zvi4Cxz4D/++iFgRGNUxdxFmnWMcWLb8SV7/0aGESlWchTfqTkqjD1CUPOED73 3MBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747044634; x=1747649434; h=in-reply-to:from:references:to:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=XPyJ6o3OXpys9hf967nLzC11+wK2eMIoU5aWrum7yco=; b=f8pwe9rRbk/0BZgAZj8rJoUbat84tq3UspGsrD4IiNl14o1pu6nJFHdtHVzpzyVCL/ Jy9GXLu0VMr5BS5u2GvlOkDnuFQOis7xbWyz/ycp1PuHUO36jQ/9LSbEVnT+GYFNKtn8 CR5nsWNF9tA96DWOWpxR0cW7JAc0b9BTu2elZNIZG7CHUrPnKpJKDvgKszQkvNFOXRLH 3oRPvcLD+B0k8PF9OAtWCLHYiDwps7kJAGPzurukx0LoS2lFu7PxYjf+FCG9kDkcpXgw Vz9lajWx504BzRbSp6urAz5f5bUb/6BgIw23DP9g8Z6WpZPQH/1VFieFRXFJzWViIpRT 4uLw== X-Forwarded-Encrypted: i=1; AJvYcCWF+BTKTXwGt2MnT+4CWUrLgTQZDoJr5GqICDdvH2rIHniwCvMZ2C5igKikMFqHEkSPBLw=@dpdk.org X-Gm-Message-State: AOJu0YyVaLMnUU8bdJADk2YcWyYkOg1fhvGGug/fw1Udazw5++fmOCn2 8mie7MYVWcVqkzCLnR9dkUNw6alZ1MDDn0PA5lLQ/wK+vRzQXWGeWHKjfSXF X-Gm-Gg: ASbGncutUM+TkpliM5Ddpwd1CDM9kJX+mvXmdhPqlakeo9ElpUiVvcC3nkcdydUJ0Bf CimEi/fzFJEdAR8L/GQPZe340oNi4v4dFmXYz+n3krLTTr2TCSsgdA/XSX10ShLJH0U6UCgd5q9 0r+KXg8/LioqiYcgHEqNYyi5G8BXKhclyPdD9aeXY4Uw6ZGYQQalERQxKDsxP2dayNSee20fC/5 nYyyk6xZ5gqY+LrQyswZxFfcxZ7N9uEfhnokxBGv8wfK0qBnN9ME0SfleCRYEXWVzKdCRwvmaee aDvv+b6/MTT64AqljWVwFk3gEhzyrpjKIZPJGY4OYE40bzh1ELLbwl0obxZ751+tgsUbNTVPJeo 0 X-Google-Smtp-Source: AGHT+IH4cA9ZOWWtoVnRU1jJ6+IN2rSoFVOGjrjzX6TljnzaXtJlqsdUx9H8KEtuVYm88M7Ray9iEw== X-Received: by 2002:a17:902:fc4e:b0:21a:8300:b9d5 with SMTP id d9443c01a7336-22fc8b59787mr202594555ad.23.1747044634004; Mon, 12 May 2025 03:10:34 -0700 (PDT) Received: from [192.168.31.141] ([183.134.173.124]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-22fc8271a7dsm59910545ad.153.2025.05.12.03.10.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 May 2025 03:10:33 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------3d2Pn3ROE9VDOvoipafQBt1v" Message-ID: <7cf98921-1ca2-4707-a0fd-609c1d2cce65@gmail.com> Date: Mon, 12 May 2025 18:10:30 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/2] crypto/ipsec_mb: fix QP release in secondary To: "Ji, Kai" , Yang Ming , "dev@dpdk.org" References: <20250314103638.2198-1-ming.1.yang@nokia-sbell.com> <20250407052532.1913-1-ming.1.yang@nokia-sbell.com> <20250407052532.1913-2-ming.1.yang@nokia-sbell.com> <6d31ea07-8bbb-4e9c-ab88-be50e0132e31@nokia-sbell.com> From: Moses Young In-Reply-To: X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org This is a multi-part message in MIME format. --------------3d2Pn3ROE9VDOvoipafQBt1v Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 5/7/2025 11:25 PM, Ji, Kai wrote: > Hi Yangming, > > PID check is implemented here: > https://github.com/DPDK/dpdk/blob/75f179ebe347b6098cf3af26d3d3b7168fe3fe24/drivers/crypto/ipsec_mb/ipsec_mb_ops.c#L376 > > > Can you share the steps to re-produce the error ? > > Regards > > Kai > > ------------------------------------------------------------------------ > *From:* Yang Ming > *Sent:* Thursday, April 24, 2025 15:26 > *To:* dev@dpdk.org > *Subject:* Re: [PATCH v2 2/2] crypto/ipsec_mb: fix QP release in > secondary > > Hi, > > On 2025/4/7 13:25, Yang Ming wrote: > > From: myang > > > > 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 > > --- > >   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? > > Brs, > > Yang Ming > Hi, David. Thanks for your feedback. I will Cc maintainers in next version. Kai, Thanks for your feedback. Here's our test steps after applying the previous patch called "eal: prevent socket closure before MP sync" in this serious: 1. Start the primary process: Run the DPDK primary process with the IPsec MB crypto device. 2. Launch the secondary process: Start a DPDK secondary process using the same device parameters. 3. Exit the secondary normally. On secondary exit, error logs show below as my commit log's description: 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 message corresponds exactly to the PID check in the code you referenced: if (qp->qp_used_by_pid != req_param->process_id) {     CDEV_LOG_ERR("Unable to release qp_id=%d", qp_id);     goto out; } In our view, this log indicates an abnormal condition: a secondary process should be able to release its own QPs without triggering an error during normal shutdown. Thanks for your help. Best, Yang Ming --------------3d2Pn3ROE9VDOvoipafQBt1v Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

On 5/7/2025 11:25 PM, Ji, Kai wrote:

Hi Yangming, 

PID check is implemented here:  
https://github.com/DPDK/dpdk/blob/75f179ebe347b6098cf3af26d3d3b7168fe3fe24/drivers/crypto/ipsec_mb/ipsec_mb_ops.c#L376

Can you share the steps to re-produce the error ?

Regards

Kai  

From: Yang Ming
Sent: Thursday, April 24, 2025 15:26
To: dev@dpdk.org
Subject: Re: [PATCH v2 2/2] crypto/ipsec_mb: fix QP release in secondary

Hi,

On 2025/4/7 13:25, Yang Ming wrote:
> From: myang <ming.1.yang@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@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?

Brs,

Yang Ming

Hi,

David. Thanks for your feedback. I will Cc maintainers in next version.

Kai, Thanks for your feedback. Here's our test steps after applying the previous patch called "eal: prevent socket closure before MP sync" in this serious:
1. Start the primary process: Run the DPDK primary process with the IPsec MB crypto device.
2. Launch the secondary process: Start a DPDK secondary process using the same device parameters.
3. Exit the secondary normally.

On secondary exit, error logs show below as my commit log's description:
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 message corresponds exactly to the PID check in the code you referenced:
if (qp->qp_used_by_pid != req_param->process_id) {
    CDEV_LOG_ERR("Unable to release qp_id=%d", qp_id);
    goto out;
}

In our view, this log indicates an abnormal condition: a secondary process should be able to release its own QPs without triggering an error during normal shutdown.

Thanks for your help.

Best,
Yang Ming --------------3d2Pn3ROE9VDOvoipafQBt1v--