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 0459A48AF9 for ; Thu, 13 Nov 2025 12:27:51 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id EF33240151; Thu, 13 Nov 2025 12:27:50 +0100 (CET) Received: from mail-qk1-f177.google.com (mail-qk1-f177.google.com [209.85.222.177]) by mails.dpdk.org (Postfix) with ESMTP id C2AD140151 for ; Thu, 13 Nov 2025 12:27:49 +0100 (CET) Received: by mail-qk1-f177.google.com with SMTP id af79cd13be357-88f8f346c2cso66679285a.0 for ; Thu, 13 Nov 2025 03:27:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763033269; x=1763638069; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=8UGfnrlqCtK7d1kjHx3SbDjCCVdueI22YfYI3m1lmzU=; b=UHpq+3RDvPrFhoID6sZ5VqHYNMcywolh6sveATVb47cqvQfqzFlmXxfSzLRyW6Pz47 r98wcLMo3bTwMgVn5kXpek7mmZKfR4jztOap0roytyVvbuUSFG+3lytzigWoqQ9/7XxF ZnkqCPai39pb8JyuRR/wbdjj/Gsskls8/GuN9Qc8FF5IbLNx0DrDS0Kz5MZcaUYD710/ 20qhmVdEKl8scTCZZtFn25OjKTL285gioqc15qQQ0DROH2XSeRt+e1X70plCvOusJpL6 gJUhJK1EOiDOF7BB8g8aDO5Lb6ReShq7CfeioLB1nsRGMFsi1jDLfnRbE09PXyG7IOIQ nBfQ== X-Forwarded-Encrypted: i=1; AJvYcCURjrRphTll8v3lIqLfktDd7MmMYwCibUHrAiqutWVRS05dWyg9JIjfLSRLWH8Q87K5a9iwui0=@dpdk.org X-Gm-Message-State: AOJu0YzRbpChVvSHj/66gJ0D/X/npx5cTNv+4+AAkBgPkjqakG+aKtkg XSwtJUwgHpnixNdfu9xTFRA7rpuSI2UlOv2J7jPZQ3g+AQYB8gKaEbIfqDEYtszPpH2zYAz/JpO 9IJCzFNRI1Jr4IKRKr/lvfPuvzpDc/C8= X-Gm-Gg: ASbGnct8ypzp6qH1/LuaWKJwyQqQAriGA1+oUrfMNkQm/XIrBj5mcXbA4/6XUTNkrFu pg81l7FDffGkc6Ho/31yL3b7Gh8j92keRdIFGFrnHiGbZp699dxJpZqfdAdjOLYOk0Xi98gfNh6 tuqdY3i/raC9SxtMNG3lH2bS3u1El17od20F+59R2i1R4P7IRI3RN2ohKvpP9SMDACrrSNUOeaO uvbj1CLIV2quM0GFbE2ucZunbDw9VQMJbixIUhAyvjCwzHZB54gorM2QkI= X-Google-Smtp-Source: AGHT+IHiAy+p5MYL93JA09gEY3NeRcoCueMb/1uUnLX/n240DwbLno1mt+zg1H5wBlFvSF3TmLi2FYNySoiiGIle9Zs= X-Received: by 2002:a05:620a:d85:b0:89e:651b:d6de with SMTP id af79cd13be357-8b29b767a00mr768743685a.13.1763033268724; Thu, 13 Nov 2025 03:27:48 -0800 (PST) MIME-Version: 1.0 References: <20251113052931.1784953-1-hemant.agrawal@nxp.com> <20251113095917.1973514-1-hemant.agrawal@nxp.com> <20251113095917.1973514-2-hemant.agrawal@nxp.com> In-Reply-To: <20251113095917.1973514-2-hemant.agrawal@nxp.com> From: Maxime Leroy Date: Thu, 13 Nov 2025 12:27:37 +0100 X-Gm-Features: AWmQ_bmo6cYJYd56zI50tGTDy0Eb2x9xvzNQiHMnqkm6sgvFY5RCU5-00TGLb2w Message-ID: Subject: Re: [PATCH v3 2/4] net/dpaa2: clear active VDQ state when freeing Rx queues To: Hemant Agrawal Cc: dev@dpdk.org, stephen@networkplumber.org, david.marchand@redhat.com, jun.yang@nxp.com, stable@dpdk.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Hi Hemant, Le jeu. 13 nov. 2025 =C3=A0 10:59, Hemant Agrawal = a =C3=A9crit : > > From: Maxime Leroy > > When using the prefetch Rx path (dpaa2_dev_prefetch_rx), the driver keeps > track of one outstanding VDQCR command per DPIO portal in the global > rte_global_active_dqs_list[] array. Each queue_storage_info_t also stores > the active result buffer and portal index: > > qs->active_dqs > qs->active_dpio_id > > Before issuing a new pull command, dpaa2_dev_prefetch_rx() checks for an > active entry and spins on qbman_check_command_complete() until the > corresponding VDQCR completes. > > On port close / hotplug remove, dpaa2_free_rx_tx_queues() frees all > per-lcore queue_storage_info_t structures and their dq_storage[] buffers, > but never clears the global rte_global_active_dqs_list[] entries. After a > detach/attach sequence (or "del/add" in grout), the prefetch Rx path > still sees an active entry for the portal and spins forever on a stale dq > buffer that has been freed and will never be completed by hardware. In > gdb, dq->dq.tok stays 0 and dpaa2_dev_prefetch_rx() loops in: > > while (!qbman_check_command_complete(get_swp_active_dqs(idx))) > ; > > Fix this by clearing the active VDQ state before freeing queue storage. > For each Rx queue and lcore, if qs->active_dqs is non-NULL, call > clear_swp_active_dqs(qs->active_dpio_id) and set qs->active_dqs to NULL. > Then dpaa2_queue_storage_free() can safely free q_storage and > dq_storage[]. > > After this change, a DPNI detach/attach sequence no longer leaves stale > entries in rte_global_active_dqs_list[], and the prefetch Rx loop does > not hang waiting for a completion from a previous device instance. > > Reproduction: > - grout: > grcli interface add port dpni.1 devargs fslmc:dpni.1 > grcli interface del dpni.1 > grcli interface add port dpni.1 devargs fslmc:dpni.1 > -> Rx was stuck in qbman_check_command_complete(), now works. > > - testpmd: > dpdk-testpmd -n1 -a fslmc:dpni.65535 -- -i --forward-mode=3Drxonly > testpmd> port attach fslmc:dpni.1 > testpmd> port start all > testpmd> start > testpmd> stop > testpmd> port stop all > testpmd> port detach 0 > testpmd> port attach fslmc:dpni.1 > testpmd> port start all > testpmd> start > -> Rx was hanging, now runs normal > > Fixes: 12d98eceb8ac ("bus/fslmc: enhance QBMAN DQ storage logic") > Cc: jun.yang@nxp.com > Cc: stable@dpdk.org > > Signed-off-by: Maxime Leroy > --- > .mailmap | 2 +- > drivers/net/dpaa2/dpaa2_ethdev.c | 22 ++++++++++++++++++++++ > 2 files changed, 23 insertions(+), 1 deletion(-) > > diff --git a/.mailmap b/.mailmap > index 10c37a97a6..d92d4fc24b 100644 > --- a/.mailmap > +++ b/.mailmap > @@ -1035,7 +1035,7 @@ Mauricio Vasquez B Mauro Annarumma > Maxime Coquelin > Maxime Gouin > -Maxime Leroy > +Maxime Leroy > Md Fahad Iqbal Polash > Megha Ajmera > Meijuan Zhao > diff --git a/drivers/net/dpaa2/dpaa2_ethdev.c b/drivers/net/dpaa2/dpaa2_e= thdev.c > index fc63cf4f09..c94034104a 100644 > --- a/drivers/net/dpaa2/dpaa2_ethdev.c > +++ b/drivers/net/dpaa2/dpaa2_ethdev.c > @@ -631,6 +631,27 @@ dpaa2_alloc_rx_tx_queues(struct rte_eth_dev *dev) > return ret; > } > > +static void > +dpaa2_clear_queue_active_dps(struct dpaa2_queue *q) > +{ > + int lcore_id; > + > + RTE_LCORE_FOREACH(lcore_id) { RTE_LCORE_FOREACH does not iterate over NON-EAL threads. However, Grout creates NON-EAL threads using the pthread library to poll the RX queue. As a result, using RTE_LCORE_FOREACH breaks the fix. We should revert to the previous version of the fix. Thanks, Maxime Leroy