patch 'bus/dpaa: fix PFDRs leaks due to FQRNIs' has been queued to stable release 21.11.9
Kevin Traynor
ktraynor at redhat.com
Wed Nov 27 18:17:56 CET 2024
Hi,
FYI, your patch has been queued to stable release 21.11.9
Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable yet.
It will be pushed if I get no objections before 12/02/24. So please
shout if anyone has objections.
Also note that after the patch there's a diff of the upstream commit vs the
patch applied to the branch. This will indicate if there was any rebasing
needed to apply to the stable branch. If there were code changes for rebasing
(ie: not only metadata diffs), please double check that the rebase was
correctly done.
Queued patches are on a temporary branch at:
https://github.com/kevintraynor/dpdk-stable
This queued commit can be viewed at:
https://github.com/kevintraynor/dpdk-stable/commit/b3787113fa8815a9c46c24ee7c5589e3031fc008
Thanks.
Kevin
---
>From b3787113fa8815a9c46c24ee7c5589e3031fc008 Mon Sep 17 00:00:00 2001
From: Gagandeep Singh <g.singh at nxp.com>
Date: Tue, 1 Oct 2024 16:33:08 +0530
Subject: [PATCH] bus/dpaa: fix PFDRs leaks due to FQRNIs
[ upstream commit b292acc3c4a8fd5104cfdfa5c6d3d0df95b6543b ]
When a Retire FQ command is executed on a FQ in the
Tentatively Scheduled or Parked states, in that case FQ
is retired immediately and a FQRNI (Frame Queue Retirement
Notification Immediate) message is generated. Software
must read this message from MR and consume it to free
the memory used by it.
Although it is not mentioned about which memory to be used
by FQRNIs in the RM but through experiments it is proven
that it can use PFDRs. So if these messages are allowed to
build up indefinitely then PFDR resources can become exhausted
and cause enqueues to stall. Therefore software must consume
these MR messages on a regular basis to avoid depleting
the available PFDR resources.
This is the PFDRs leak issue which user can experience while
using the DPDK crypto driver and creating and destroying the
sessions multiple times. On a session destroy, DPDK calls the
qman_retire_fq() for each FQ used by the session, but it does
not handle the FQRNIs generated and allowed them to build up
indefinitely in MR.
This patch fixes this issue by consuming the FQRNIs received
from MR immediately after FQ retire by calling drain_mr_fqrni().
Please note that this drain_mr_fqrni() only look for
FQRNI type messages to consume. If there are other type of messages
like FQRN, FQRL, FQPN, ERN etc. also coming on MR then those
messages need to be handled separately.
Fixes: c47ff048b99a ("bus/dpaa: add QMAN driver core routines")
Signed-off-by: Gagandeep Singh <g.singh at nxp.com>
Acked-by: Hemant Agrawal <hemant.agrawal at nxp.com>
---
drivers/bus/dpaa/base/qbman/qman.c | 46 ++++++++++++++++--------------
1 file changed, 25 insertions(+), 21 deletions(-)
diff --git a/drivers/bus/dpaa/base/qbman/qman.c b/drivers/bus/dpaa/base/qbman/qman.c
index aa8da96627..c5e66d4325 100644
--- a/drivers/bus/dpaa/base/qbman/qman.c
+++ b/drivers/bus/dpaa/base/qbman/qman.c
@@ -295,8 +295,30 @@ static inline void qman_stop_dequeues_ex(struct qman_portal *p)
}
+static inline void qm_mr_pvb_update(struct qm_portal *portal)
+{
+ register struct qm_mr *mr = &portal->mr;
+ const struct qm_mr_entry *res = qm_cl(mr->ring, mr->pi);
+
+#ifdef RTE_LIBRTE_DPAA_HWDEBUG
+ DPAA_ASSERT(mr->pmode == qm_mr_pvb);
+#endif
+ /* when accessing 'verb', use __raw_readb() to ensure that compiler
+ * inlining doesn't try to optimise out "excess reads".
+ */
+ if ((__raw_readb(&res->ern.verb) & QM_MR_VERB_VBIT) == mr->vbit) {
+ mr->pi = (mr->pi + 1) & (QM_MR_SIZE - 1);
+ if (!mr->pi)
+ mr->vbit ^= QM_MR_VERB_VBIT;
+ mr->fill++;
+ res = MR_INC(res);
+ }
+ dcbit_ro(res);
+}
+
static int drain_mr_fqrni(struct qm_portal *p)
{
const struct qm_mr_entry *msg;
loop:
+ qm_mr_pvb_update(p);
msg = qm_mr_current(p);
if (!msg) {
@@ -320,4 +342,5 @@ loop:
now = mfatb();
} while ((then + 10000) > now);
+ qm_mr_pvb_update(p);
msg = qm_mr_current(p);
if (!msg)
@@ -482,25 +505,4 @@ static inline int qm_mr_init(struct qm_portal *portal,
}
-static inline void qm_mr_pvb_update(struct qm_portal *portal)
-{
- register struct qm_mr *mr = &portal->mr;
- const struct qm_mr_entry *res = qm_cl(mr->ring, mr->pi);
-
-#ifdef RTE_LIBRTE_DPAA_HWDEBUG
- DPAA_ASSERT(mr->pmode == qm_mr_pvb);
-#endif
- /* when accessing 'verb', use __raw_readb() to ensure that compiler
- * inlining doesn't try to optimise out "excess reads".
- */
- if ((__raw_readb(&res->ern.verb) & QM_MR_VERB_VBIT) == mr->vbit) {
- mr->pi = (mr->pi + 1) & (QM_MR_SIZE - 1);
- if (!mr->pi)
- mr->vbit ^= QM_MR_VERB_VBIT;
- mr->fill++;
- res = MR_INC(res);
- }
- dcbit_ro(res);
-}
-
struct qman_portal *
qman_init_portal(struct qman_portal *portal,
@@ -1826,4 +1828,6 @@ int qman_retire_fq(struct qman_fq *fq, u32 *flags)
out:
FQUNLOCK(fq);
+ /* Draining FQRNIs, if any */
+ drain_mr_fqrni(&p->p);
return rval;
}
--
2.47.0
---
Diff of the applied patch vs upstream commit (please double-check if non-empty:
---
--- - 2024-11-27 17:17:39.821021435 +0000
+++ 0049-bus-dpaa-fix-PFDRs-leaks-due-to-FQRNIs.patch 2024-11-27 17:17:38.223269363 +0000
@@ -1 +1 @@
-From b292acc3c4a8fd5104cfdfa5c6d3d0df95b6543b Mon Sep 17 00:00:00 2001
+From b3787113fa8815a9c46c24ee7c5589e3031fc008 Mon Sep 17 00:00:00 2001
@@ -5,0 +6,2 @@
+[ upstream commit b292acc3c4a8fd5104cfdfa5c6d3d0df95b6543b ]
+
@@ -37 +38,0 @@
-Cc: stable at dpdk.org
@@ -46 +47 @@
-index 301057723e..9c90ee25a6 100644
+index aa8da96627..c5e66d4325 100644
@@ -49 +50 @@
-@@ -293,8 +293,30 @@ static inline void qman_stop_dequeues_ex(struct qman_portal *p)
+@@ -295,8 +295,30 @@ static inline void qman_stop_dequeues_ex(struct qman_portal *p)
@@ -80 +81 @@
-@@ -318,4 +340,5 @@ loop:
+@@ -320,4 +342,5 @@ loop:
@@ -86 +87 @@
-@@ -480,25 +503,4 @@ static inline int qm_mr_init(struct qm_portal *portal,
+@@ -482,25 +505,4 @@ static inline int qm_mr_init(struct qm_portal *portal,
@@ -112 +113 @@
-@@ -1795,4 +1797,6 @@ int qman_retire_fq(struct qman_fq *fq, u32 *flags)
+@@ -1826,4 +1828,6 @@ int qman_retire_fq(struct qman_fq *fq, u32 *flags)
More information about the stable
mailing list