patch 'net/bnxt: fix VF RSS hash mode configuration' has been queued to stable release 24.11.9
luca.boccassi at gmail.com
luca.boccassi at gmail.com
Tue Oct 27 12:51:01 CET 2026
Hi,
FYI, your patch has been queued to stable release 24.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 10/29/26. 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/bluca/dpdk-stable
This queued commit can be viewed at:
https://github.com/bluca/dpdk-stable/commit/b8f070f98d70ad7d6c3a067ab09dd9bd62abd9ea
Thanks.
Luca Boccassi
---
>From b8f070f98d70ad7d6c3a067ab09dd9bd62abd9ea Mon Sep 17 00:00:00 2001
From: Mohammad Shuab Siddique <mohammad-shuab.siddique at broadcom.com>
Date: Wed, 17 Jun 2026 12:41:35 -0600
Subject: [PATCH] net/bnxt: fix VF RSS hash mode configuration
[ upstream commit c0dac52fce560eb40d8a0b497363f10340290d90 ]
In bnxt_hwrm_vnic_rss_cfg_hash_mode_p5(), the VF path unconditionally
accessed vnic->fw_grp_ids[0], but fw_grp_ids is NULL when no RSS
contexts have been allocated (num_lb_ctxts == 0). The
bnxt_hwrm_vnic_rss_cfg_p5() call just before it skips its loop when
num_lb_ctxts == 0, so the NULL pointer passed through silently to
this function and caused a segfault on the next RSS hash-level
change after port stop.
A separate HWRM_VNIC_RSS_CFG call to set hash_mode on its own, with
ring_grp_tbl_addr=0 and hash_type=0, is also unsafe on P5/P7 VFs:
firmware treats those zeroes literally and wipes the ring table, so
all traffic lands on queue 0 regardless of the configured RSS level.
Set hash_mode_flags directly in bnxt_hwrm_vnic_rss_cfg_p5() for VFs
on P5/P7, translating DEFAULT to INNERMOST. Firmware now receives one
complete call per context with the ring table, hash type, and hash
mode all set together.
Embedding hash_mode_flags there alone would permanently short-circuit
the separate hash-mode call in bnxt_hwrm_vnic_rss_cfg_hash_mode_p5()
for every VF, silently dropping a trusted VF's explicit RSS
hash-level request (e.g. "rss level-outer") no matter what value was
requested. Firmware's own gate for that separate call (vnic_id ==
0xFFFF && rss_ctx_idx == 0xFFFF) explicitly permits trusted VFs, not
just PFs, to use it. So instead of skipping VFs unconditionally,
bnxt_hwrm_vnic_rss_cfg_hash_mode_p5() now only short-circuits for a
VF that is untrusted or has no initialized RSS context (fw_grp_ids/
num_lb_ctxts), and lets a trusted VF with an initialized context
reach the same call PFs already use. The per-context ring-table-wipe
fix above is unchanged either way.
Fixes: 3fd58de5a903 ("net/bnxt: fix RSS hash mode configuration for VF")
Signed-off-by: Farah Smith <farah.smith at broadcom.com>
Signed-off-by: Mohammad Shuab Siddique <mohammad-shuab.siddique at broadcom.com>
---
drivers/net/bnxt/bnxt_hwrm.c | 79 +++++++++++++-----------------------
1 file changed, 28 insertions(+), 51 deletions(-)
diff --git a/drivers/net/bnxt/bnxt_hwrm.c b/drivers/net/bnxt/bnxt_hwrm.c
index 9e7aa4acecc..8d0013ebefc 100644
--- a/drivers/net/bnxt/bnxt_hwrm.c
+++ b/drivers/net/bnxt/bnxt_hwrm.c
@@ -2912,15 +2912,16 @@ bnxt_hwrm_vnic_rss_cfg_p5(struct bnxt *bp, struct bnxt_vnic_info *vnic)
req.vnic_id = rte_cpu_to_le_16(vnic->fw_vnic_id);
req.hash_type = rte_cpu_to_le_32(bnxt_sanitize_rss_type(bp, vnic->hash_type));
- /* Update req with vnic ring_select_mode for P7 */
if (BNXT_CHIP_P7(bp))
req.ring_select_mode = vnic->ring_select_mode;
- /* When the vnic_id in the request field is a valid
- * one, the hash_mode_flags in the request field must
- * be set to DEFAULT. And any request to change the
- * default behavior must be done in a separate call
- * to HWRM_VNIC_RSS_CFG by exclusively setting hash
- * mode and vnic_id, rss_ctx_idx to INVALID.
+
+ /* Do not embed hash_mode_flags here for VFs. Doing so, plus
+ * syncing prev_hash_mode below, permanently short-circuits
+ * bnxt_hwrm_vnic_rss_cfg_hash_mode_p5()'s guard for every VF,
+ * so a trusted VF's explicit RSS hash-level request (e.g.
+ * rss level-outer) is silently dropped. Firmware's own gate
+ * (vnic_rss_cfg_cmd()) permits trusted VFs on that call, so
+ * treat VFs the same as PFs here.
*/
req.hash_mode_flags = BNXT_HASH_MODE_DEFAULT;
@@ -2949,70 +2950,46 @@ static int
bnxt_hwrm_vnic_rss_cfg_hash_mode_p5(struct bnxt *bp, struct bnxt_vnic_info *vnic)
{
struct hwrm_vnic_rss_cfg_output *resp = bp->hwrm_cmd_resp_addr;
- struct hwrm_vnic_rss_cfg_input req = {.req_type = 0 };
+ struct hwrm_vnic_rss_cfg_input req = {.req_type = 0};
int rc = 0;
- /* The reason we are returning success here is that this
- * call is in the context of user/stack RSS configuration.
- * Even though OUTER RSS is not supported, the normal RSS
- * configuration should continue to work.
- */
+ /* Return success when outer RSS is unsupported so normal RSS works. */
if ((BNXT_CHIP_P5(bp) && BNXT_VNIC_OUTER_RSS_UNSUPPORTED(bp)) ||
(!BNXT_CHIP_P5(bp) && !(bp->vnic_cap_flags & BNXT_VNIC_CAP_OUTER_RSS)))
return 0;
- /* TODO Revisit for Thor 2 */
- /* if (BNXT_CHIP_P5_P7(bp))
- * bnxt_hwrm_vnic_rss_cfg_p5(bp, vnic);
- */
- /* Don't call RSS hash level configuration if the current
- * hash level is the same as the hash level that is requested.
- */
if (vnic->prev_hash_mode == vnic->hash_mode)
return 0;
+ /* Trusted VFs now reach this call the same as PFs; firmware's own
+ * gate (IS_PF_FID() || pcie_func_is_trusted_vf()) restricts which
+ * callers it accepts the request from. Firmware would reject a
+ * request from an untrusted VF, so keep it a silent no-op here
+ * instead of surfacing a new HWRM error.
+ * The fw_grp_ids/num_lb_ctxts check guards against a NULL RSS
+ * context that is not yet initialized or has been torn down by
+ * a port stop.
+ */
+ if (BNXT_VF(bp) &&
+ (!BNXT_VF_IS_TRUSTED(bp) || !vnic->fw_grp_ids || !vnic->num_lb_ctxts))
+ return 0;
+
HWRM_PREP(&req, HWRM_VNIC_RSS_CFG, BNXT_USE_CHIMP_MB);
- /* For FW, hash_mode == DEFAULT means that
- * the FW is capable of doing INNER & OUTER RSS as well.
- * DEFAULT doesn't mean that the FW is
- * going to change the hash_mode to INNER. However, for
- * the USER, DEFAULT means, change the hash mode to the
- * NIC's DEFAULT hash mode which is INNER.
- *
- * Hence, driver should make the translation of hash_mode
- * to INNERMOST when hash_mode from the dpdk stack is
- * DEFAULT.
+ /* FW DEFAULT keeps existing hash level; translate to INNERMOST so
+ * the NIC uses its hardware default (inner headers).
*/
if (vnic->hash_mode == BNXT_HASH_MODE_DEFAULT)
req.hash_mode_flags = BNXT_HASH_MODE_INNERMOST;
else
req.hash_mode_flags = vnic->hash_mode;
- /* VFs must use actual vnic_id for per-VNIC configuration.
- * PFs can use INVALID vnic_id for global configuration.
- * This is because VFs don't have permission to configure
- * global hash mode, even if they're trusted.
- */
- if (BNXT_VF(bp)) {
- req.vnic_id = rte_cpu_to_le_16(vnic->fw_vnic_id);
- req.rss_ctx_idx = rte_cpu_to_le_16(vnic->fw_grp_ids[0]);
- PMD_DRV_LOG_LINE(DEBUG, "VF using per-VNIC RSS config (vnic_id=%u)",
- vnic->fw_vnic_id);
- } else {
- req.vnic_id = rte_cpu_to_le_16(BNXT_DFLT_VNIC_ID_INVALID);
- req.rss_ctx_idx = rte_cpu_to_le_16(BNXT_RSS_CTX_IDX_INVALID);
- PMD_DRV_LOG_LINE(DEBUG, "PF using global RSS config");
- }
-
+ req.vnic_id = rte_cpu_to_le_16(BNXT_DFLT_VNIC_ID_INVALID);
+ req.rss_ctx_idx = rte_cpu_to_le_16(BNXT_RSS_CTX_IDX_INVALID);
PMD_DRV_LOG_LINE(DEBUG, "RSS CFG: Hash level %d", req.hash_mode_flags);
- rc = bnxt_hwrm_send_message(bp, &req, sizeof(req),
- BNXT_USE_CHIMP_MB);
+ rc = bnxt_hwrm_send_message(bp, &req, sizeof(req), BNXT_USE_CHIMP_MB);
HWRM_CHECK_RESULT();
- /* Store the programmed hash_mode in prev_hash_mode so that
- * it can checked against the next user requested hash mode.
- */
if (!rc)
vnic->prev_hash_mode = vnic->hash_mode;
HWRM_UNLOCK();
--
2.47.3
---
Diff of the applied patch vs upstream commit (please double-check if non-empty:
---
--- - 2026-10-27 11:44:00.128470614 +0000
+++ 0167-net-bnxt-fix-VF-RSS-hash-mode-configuration.patch 2026-10-27 11:43:53.746066629 +0000
@@ -1 +1 @@
-From c0dac52fce560eb40d8a0b497363f10340290d90 Mon Sep 17 00:00:00 2001
+From b8f070f98d70ad7d6c3a067ab09dd9bd62abd9ea Mon Sep 17 00:00:00 2001
@@ -5,0 +6,2 @@
+[ upstream commit c0dac52fce560eb40d8a0b497363f10340290d90 ]
+
@@ -38 +39,0 @@
-Cc: stable at dpdk.org
@@ -47 +48 @@
-index 79ad2cbafd..93fe754ced 100644
+index 9e7aa4acecc..8d0013ebefc 100644
@@ -50 +51 @@
-@@ -2880,15 +2880,16 @@ bnxt_hwrm_vnic_rss_cfg_p5(struct bnxt *bp, struct bnxt_vnic_info *vnic)
+@@ -2912,15 +2912,16 @@ bnxt_hwrm_vnic_rss_cfg_p5(struct bnxt *bp, struct bnxt_vnic_info *vnic)
@@ -74 +75 @@
-@@ -2917,70 +2918,46 @@ static int
+@@ -2949,70 +2950,46 @@ static int
More information about the stable
mailing list