[PATCH net V2 00/11] mlx5 misc fixes 2025-08-25

[PATCH net V2 00/11] mlx5 misc fixes 2025-08-25

[Mark Bloch]

Hi,

This patchset provides misc bug fixes from the team to the mlx5 core and
Eth drivers.

V1: https://lore.kernel.org/all/20250824083944.523858-1-mbloch@nvidia.com/

Changelog:

V1->V2:
- Patch 9 was fixed to address build warning found by kernel test robot.

Alexei Lazar (3):
  net/mlx5e: Update and set Xon/Xoff upon MTU set
  net/mlx5e: Update and set Xon/Xoff upon port speed set
  net/mlx5e: Set local Xoff after FW update

Lama Kayal (4):
  net/mlx5: HWS, Fix memory leak in hws_pool_buddy_init error path
  net/mlx5: HWS, Fix memory leak in hws_action_get_shared_stc_nic error flow
  net/mlx5: HWS, Fix uninitialized variables in mlx5hws_pat_calc_nop error flow
  net/mlx5: HWS, Fix pattern destruction in mlx5hws_pat_get_pattern error path

Moshe Shemesh (4):
  net/mlx5: Reload auxiliary drivers on fw_activate
  net/mlx5: Fix lockdep assertion on sync reset unload event
  net/mlx5: Nack sync reset when SFs are present
  net/mlx5: Prevent flow steering mode changes in switchdev mode

 .../net/ethernet/mellanox/mlx5/core/devlink.c |   2 +-
 .../mellanox/mlx5/core/en/port_buffer.c       |   3 +-
 .../mellanox/mlx5/core/en/port_buffer.h       |  12 ++
 .../net/ethernet/mellanox/mlx5/core/en_main.c |  19 ++-
 .../net/ethernet/mellanox/mlx5/core/fs_core.c |  15 +--
 .../ethernet/mellanox/mlx5/core/fw_reset.c    | 126 ++++++++++--------
 .../ethernet/mellanox/mlx5/core/fw_reset.h    |   1 +
 .../ethernet/mellanox/mlx5/core/sf/devlink.c  |  10 ++
 .../net/ethernet/mellanox/mlx5/core/sf/sf.h   |   6 +
 .../mellanox/mlx5/core/steering/hws/action.c  |   2 +-
 .../mellanox/mlx5/core/steering/hws/pat_arg.c |   6 +-
 .../mellanox/mlx5/core/steering/hws/pool.c    |   1 +
 12 files changed, 136 insertions(+), 67 deletions(-)


base-commit: ec79003c5f9d2c7f9576fc69b8dbda80305cbe3a
-- 
2.34.1

[PATCH net V2 01/11] net/mlx5: HWS, Fix memory leak in hws_pool_buddy_init error path

[Mark Bloch]

From: Lama Kayal <lkayal@nvidia.com>

In the error path of hws_pool_buddy_init(), the buddy allocator cleanup
doesn't free the allocator structure itself, causing a memory leak.

Add the missing kfree() to properly release all allocated memory.

Fixes: c61afff94373 ("net/mlx5: HWS, added memory management handling")
Signed-off-by: Lama Kayal <lkayal@nvidia.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Signed-off-by: Mark Bloch <mbloch@nvidia.com>
---
 drivers/net/ethernet/mellanox/mlx5/core/steering/hws/pool.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/pool.c b/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/pool.c
index 7e37d6e9eb83..7b5071c3df36 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/pool.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/pool.c
@@ -124,6 +124,7 @@ static int hws_pool_buddy_init(struct mlx5hws_pool *pool)
 		mlx5hws_err(pool->ctx, "Failed to create resource type: %d size %zu\n",
 			    pool->type, pool->alloc_log_sz);
 		mlx5hws_buddy_cleanup(buddy);
+		kfree(buddy);
 		return -ENOMEM;
 	}
 
-- 
2.34.1

[PATCH net V2 02/11] net/mlx5: HWS, Fix memory leak in hws_action_get_shared_stc_nic error flow

[Mark Bloch]

From: Lama Kayal <lkayal@nvidia.com>

When an invalid stc_type is provided, the function allocates memory for
shared_stc but jumps to unlock_and_out without freeing it, causing a
memory leak.

Fix by jumping to free_shared_stc label instead to ensure proper cleanup.

Fixes: 504e536d9010 ("net/mlx5: HWS, added actions handling")
Signed-off-by: Lama Kayal <lkayal@nvidia.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Signed-off-by: Mark Bloch <mbloch@nvidia.com>
---
 drivers/net/ethernet/mellanox/mlx5/core/steering/hws/action.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/action.c b/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/action.c
index 396804369b00..6b36a4a7d895 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/action.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/action.c
@@ -117,7 +117,7 @@ static int hws_action_get_shared_stc_nic(struct mlx5hws_context *ctx,
 		mlx5hws_err(ctx, "No such stc_type: %d\n", stc_type);
 		pr_warn("HWS: Invalid stc_type: %d\n", stc_type);
 		ret = -EINVAL;
-		goto unlock_and_out;
+		goto free_shared_stc;
 	}
 
 	ret = mlx5hws_action_alloc_single_stc(ctx, &stc_attr, tbl_type,
-- 
2.34.1

[PATCH net V2 03/11] net/mlx5: HWS, Fix uninitialized variables in mlx5hws_pat_calc_nop error flow

[Mark Bloch]

From: Lama Kayal <lkayal@nvidia.com>

In mlx5hws_pat_calc_nop(), src_field and dst_field are passed to
hws_action_modify_get_target_fields() which should set their values.
However, if an invalid action type is encountered, these variables
remain uninitialized and are later used to update prev_src_field
and prev_dst_field.

Initialize both variables to INVALID_FIELD to ensure they have
defined values in all code paths.

Fixes: 01e035fd0380 ("net/mlx5: HWS, handle modify header actions dependency")
Signed-off-by: Lama Kayal <lkayal@nvidia.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Signed-off-by: Mark Bloch <mbloch@nvidia.com>
---
 .../net/ethernet/mellanox/mlx5/core/steering/hws/pat_arg.c    | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/pat_arg.c b/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/pat_arg.c
index 51e4c551e0ef..622fd579f140 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/pat_arg.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/pat_arg.c
@@ -527,7 +527,6 @@ int mlx5hws_pat_calc_nop(__be64 *pattern, size_t num_actions,
 			 u32 *nop_locations, __be64 *new_pat)
 {
 	u16 prev_src_field = INVALID_FIELD, prev_dst_field = INVALID_FIELD;
-	u16 src_field, dst_field;
 	u8 action_type;
 	bool dependent;
 	size_t i, j;
@@ -539,6 +538,9 @@ int mlx5hws_pat_calc_nop(__be64 *pattern, size_t num_actions,
 		return 0;
 
 	for (i = 0, j = 0; i < num_actions; i++, j++) {
+		u16 src_field = INVALID_FIELD;
+		u16 dst_field = INVALID_FIELD;
+
 		if (j >= max_actions)
 			return -EINVAL;
 
-- 
2.34.1

[PATCH net V2 04/11] net/mlx5: HWS, Fix pattern destruction in mlx5hws_pat_get_pattern error path

[Mark Bloch]

From: Lama Kayal <lkayal@nvidia.com>

In mlx5hws_pat_get_pattern(), when mlx5hws_pat_add_pattern_to_cache()
fails, the function attempts to clean up the pattern created by
mlx5hws_cmd_header_modify_pattern_create(). However, it incorrectly
uses *pattern_id which hasn't been set yet, instead of the local
ptrn_id variable that contains the actual pattern ID.

This results in attempting to destroy a pattern using uninitialized
data from the output parameter, rather than the valid pattern ID
returned by the firmware.

Use ptrn_id instead of *pattern_id in the cleanup path to properly
destroy the created pattern.

Fixes: aefc15a0fa1c ("net/mlx5: HWS, added modify header pattern and args handling")
Signed-off-by: Lama Kayal <lkayal@nvidia.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Signed-off-by: Mark Bloch <mbloch@nvidia.com>
---
 drivers/net/ethernet/mellanox/mlx5/core/steering/hws/pat_arg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/pat_arg.c b/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/pat_arg.c
index 622fd579f140..d56271a9e4f0 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/pat_arg.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/pat_arg.c
@@ -279,7 +279,7 @@ int mlx5hws_pat_get_pattern(struct mlx5hws_context *ctx,
 	return ret;
 
 clean_pattern:
-	mlx5hws_cmd_header_modify_pattern_destroy(ctx->mdev, *pattern_id);
+	mlx5hws_cmd_header_modify_pattern_destroy(ctx->mdev, ptrn_id);
 out_unlock:
 	mutex_unlock(&ctx->pattern_cache->lock);
 	return ret;
-- 
2.34.1

[PATCH net V2 05/11] net/mlx5: Reload auxiliary drivers on fw_activate

[Mark Bloch]

From: Moshe Shemesh <moshe@nvidia.com>

The devlink reload fw_activate command performs firmware activation
followed by driver reload, while devlink reload driver_reinit triggers
only driver reload. However, the driver reload logic differs between the
two modes, as on driver_reinit mode mlx5 also reloads auxiliary drivers,
while in fw_activate mode the auxiliary drivers are suspended where
applicable.

Additionally, following the cited commit, if the device has multiple PFs,
the behavior during fw_activate may vary between PFs: one PF may suspend
auxiliary drivers, while another reloads them.

Align devlink dev reload fw_activate behavior with devlink dev reload
driver_reinit, to reload all auxiliary drivers.

Fixes: 72ed5d5624af ("net/mlx5: Suspend auxiliary devices only in case of PCI device suspend")
Signed-off-by: Moshe Shemesh <moshe@nvidia.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Reviewed-by: Akiva Goldberger <agoldberger@nvidia.com>
Signed-off-by: Mark Bloch <mbloch@nvidia.com>
---
 drivers/net/ethernet/mellanox/mlx5/core/devlink.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/devlink.c b/drivers/net/ethernet/mellanox/mlx5/core/devlink.c
index 3ffa3fbacd16..26091e7536d3 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/devlink.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/devlink.c
@@ -160,7 +160,7 @@ static int mlx5_devlink_reload_fw_activate(struct devlink *devlink, struct netli
 	if (err)
 		return err;
 
-	mlx5_unload_one_devl_locked(dev, true);
+	mlx5_unload_one_devl_locked(dev, false);
 	err = mlx5_health_wait_pci_up(dev);
 	if (err)
 		NL_SET_ERR_MSG_MOD(extack, "FW activate aborted, PCI reads fail after reset");
-- 
2.34.1

[PATCH net V2 06/11] net/mlx5: Fix lockdep assertion on sync reset unload event

[Mark Bloch]

From: Moshe Shemesh <moshe@nvidia.com>

Fix lockdep assertion triggered during sync reset unload event. When the
sync reset flow is initiated using the devlink reload fw_activate
option, the PF already holds the devlink lock while handling unload
event. In this case, delegate sync reset unload event handling back to
the devlink callback process to avoid double-locking and resolve the
lockdep warning.

Kernel log:
WARNING: CPU: 9 PID: 1578 at devl_assert_locked+0x31/0x40
[...]
Call Trace:
<TASK>
 mlx5_unload_one_devl_locked+0x2c/0xc0 [mlx5_core]
 mlx5_sync_reset_unload_event+0xaf/0x2f0 [mlx5_core]
 process_one_work+0x222/0x640
 worker_thread+0x199/0x350
 kthread+0x10b/0x230
 ? __pfx_worker_thread+0x10/0x10
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x8e/0x100
 ? __pfx_kthread+0x10/0x10
 ret_from_fork_asm+0x1a/0x30
</TASK>

Fixes: 7a9770f1bfea ("net/mlx5: Handle sync reset unload event")
Signed-off-by: Moshe Shemesh <moshe@nvidia.com>
Signed-off-by: Mark Bloch <mbloch@nvidia.com>
---
 .../net/ethernet/mellanox/mlx5/core/devlink.c |   2 +-
 .../ethernet/mellanox/mlx5/core/fw_reset.c    | 120 ++++++++++--------
 .../ethernet/mellanox/mlx5/core/fw_reset.h    |   1 +
 3 files changed, 69 insertions(+), 54 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/devlink.c b/drivers/net/ethernet/mellanox/mlx5/core/devlink.c
index 26091e7536d3..2c0e0c16ca90 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/devlink.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/devlink.c
@@ -160,7 +160,7 @@ static int mlx5_devlink_reload_fw_activate(struct devlink *devlink, struct netli
 	if (err)
 		return err;
 
-	mlx5_unload_one_devl_locked(dev, false);
+	mlx5_sync_reset_unload_flow(dev, true);
 	err = mlx5_health_wait_pci_up(dev);
 	if (err)
 		NL_SET_ERR_MSG_MOD(extack, "FW activate aborted, PCI reads fail after reset");
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fw_reset.c b/drivers/net/ethernet/mellanox/mlx5/core/fw_reset.c
index 69933addd921..38b9b184ae01 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/fw_reset.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/fw_reset.c
@@ -12,7 +12,8 @@ enum {
 	MLX5_FW_RESET_FLAGS_NACK_RESET_REQUEST,
 	MLX5_FW_RESET_FLAGS_PENDING_COMP,
 	MLX5_FW_RESET_FLAGS_DROP_NEW_REQUESTS,
-	MLX5_FW_RESET_FLAGS_RELOAD_REQUIRED
+	MLX5_FW_RESET_FLAGS_RELOAD_REQUIRED,
+	MLX5_FW_RESET_FLAGS_UNLOAD_EVENT,
 };
 
 struct mlx5_fw_reset {
@@ -219,7 +220,7 @@ int mlx5_fw_reset_set_live_patch(struct mlx5_core_dev *dev)
 	return mlx5_reg_mfrl_set(dev, MLX5_MFRL_REG_RESET_LEVEL0, 0, 0, false);
 }
 
-static void mlx5_fw_reset_complete_reload(struct mlx5_core_dev *dev, bool unloaded)
+static void mlx5_fw_reset_complete_reload(struct mlx5_core_dev *dev)
 {
 	struct mlx5_fw_reset *fw_reset = dev->priv.fw_reset;
 	struct devlink *devlink = priv_to_devlink(dev);
@@ -228,8 +229,7 @@ static void mlx5_fw_reset_complete_reload(struct mlx5_core_dev *dev, bool unload
 	if (test_bit(MLX5_FW_RESET_FLAGS_PENDING_COMP, &fw_reset->reset_flags)) {
 		complete(&fw_reset->done);
 	} else {
-		if (!unloaded)
-			mlx5_unload_one(dev, false);
+		mlx5_sync_reset_unload_flow(dev, false);
 		if (mlx5_health_wait_pci_up(dev))
 			mlx5_core_err(dev, "reset reload flow aborted, PCI reads still not working\n");
 		else
@@ -272,7 +272,7 @@ static void mlx5_sync_reset_reload_work(struct work_struct *work)
 
 	mlx5_sync_reset_clear_reset_requested(dev, false);
 	mlx5_enter_error_state(dev, true);
-	mlx5_fw_reset_complete_reload(dev, false);
+	mlx5_fw_reset_complete_reload(dev);
 }
 
 #define MLX5_RESET_POLL_INTERVAL	(HZ / 10)
@@ -586,6 +586,65 @@ static int mlx5_sync_pci_reset(struct mlx5_core_dev *dev, u8 reset_method)
 	return err;
 }
 
+void mlx5_sync_reset_unload_flow(struct mlx5_core_dev *dev, bool locked)
+{
+	struct mlx5_fw_reset *fw_reset = dev->priv.fw_reset;
+	unsigned long timeout;
+	int poll_freq = 20;
+	bool reset_action;
+	u8 rst_state;
+	int err;
+
+	if (locked)
+		mlx5_unload_one_devl_locked(dev, false);
+	else
+		mlx5_unload_one(dev, false);
+
+	if (!test_bit(MLX5_FW_RESET_FLAGS_UNLOAD_EVENT, &fw_reset->reset_flags))
+		return;
+
+	mlx5_set_fw_rst_ack(dev);
+	mlx5_core_warn(dev, "Sync Reset Unload done, device reset expected\n");
+
+	reset_action = false;
+	timeout = jiffies + msecs_to_jiffies(mlx5_tout_ms(dev, RESET_UNLOAD));
+	do {
+		rst_state = mlx5_get_fw_rst_state(dev);
+		if (rst_state == MLX5_FW_RST_STATE_TOGGLE_REQ ||
+		    rst_state == MLX5_FW_RST_STATE_IDLE) {
+			reset_action = true;
+			break;
+		}
+		if (rst_state == MLX5_FW_RST_STATE_DROP_MODE) {
+			mlx5_core_info(dev, "Sync Reset Drop mode ack\n");
+			mlx5_set_fw_rst_ack(dev);
+			poll_freq = 1000;
+		}
+		msleep(poll_freq);
+	} while (!time_after(jiffies, timeout));
+
+	if (!reset_action) {
+		mlx5_core_err(dev, "Got timeout waiting for sync reset action, state = %u\n",
+			      rst_state);
+		fw_reset->ret = -ETIMEDOUT;
+		goto done;
+	}
+
+	mlx5_core_warn(dev, "Sync Reset, got reset action. rst_state = %u\n",
+		       rst_state);
+	if (rst_state == MLX5_FW_RST_STATE_TOGGLE_REQ) {
+		err = mlx5_sync_pci_reset(dev, fw_reset->reset_method);
+		if (err) {
+			mlx5_core_warn(dev, "mlx5_sync_pci_reset failed, err %d\n",
+				       err);
+			fw_reset->ret = err;
+		}
+	}
+
+done:
+	clear_bit(MLX5_FW_RESET_FLAGS_UNLOAD_EVENT, &fw_reset->reset_flags);
+}
+
 static void mlx5_sync_reset_now_event(struct work_struct *work)
 {
 	struct mlx5_fw_reset *fw_reset = container_of(work, struct mlx5_fw_reset,
@@ -613,17 +672,13 @@ static void mlx5_sync_reset_now_event(struct work_struct *work)
 	mlx5_enter_error_state(dev, true);
 done:
 	fw_reset->ret = err;
-	mlx5_fw_reset_complete_reload(dev, false);
+	mlx5_fw_reset_complete_reload(dev);
 }
 
 static void mlx5_sync_reset_unload_event(struct work_struct *work)
 {
 	struct mlx5_fw_reset *fw_reset;
 	struct mlx5_core_dev *dev;
-	unsigned long timeout;
-	int poll_freq = 20;
-	bool reset_action;
-	u8 rst_state;
 	int err;
 
 	fw_reset = container_of(work, struct mlx5_fw_reset, reset_unload_work);
@@ -632,6 +687,7 @@ static void mlx5_sync_reset_unload_event(struct work_struct *work)
 	if (mlx5_sync_reset_clear_reset_requested(dev, false))
 		return;
 
+	set_bit(MLX5_FW_RESET_FLAGS_UNLOAD_EVENT, &fw_reset->reset_flags);
 	mlx5_core_warn(dev, "Sync Reset Unload. Function is forced down.\n");
 
 	err = mlx5_cmd_fast_teardown_hca(dev);
@@ -640,49 +696,7 @@ static void mlx5_sync_reset_unload_event(struct work_struct *work)
 	else
 		mlx5_enter_error_state(dev, true);
 
-	if (test_bit(MLX5_FW_RESET_FLAGS_PENDING_COMP, &fw_reset->reset_flags))
-		mlx5_unload_one_devl_locked(dev, false);
-	else
-		mlx5_unload_one(dev, false);
-
-	mlx5_set_fw_rst_ack(dev);
-	mlx5_core_warn(dev, "Sync Reset Unload done, device reset expected\n");
-
-	reset_action = false;
-	timeout = jiffies + msecs_to_jiffies(mlx5_tout_ms(dev, RESET_UNLOAD));
-	do {
-		rst_state = mlx5_get_fw_rst_state(dev);
-		if (rst_state == MLX5_FW_RST_STATE_TOGGLE_REQ ||
-		    rst_state == MLX5_FW_RST_STATE_IDLE) {
-			reset_action = true;
-			break;
-		}
-		if (rst_state == MLX5_FW_RST_STATE_DROP_MODE) {
-			mlx5_core_info(dev, "Sync Reset Drop mode ack\n");
-			mlx5_set_fw_rst_ack(dev);
-			poll_freq = 1000;
-		}
-		msleep(poll_freq);
-	} while (!time_after(jiffies, timeout));
-
-	if (!reset_action) {
-		mlx5_core_err(dev, "Got timeout waiting for sync reset action, state = %u\n",
-			      rst_state);
-		fw_reset->ret = -ETIMEDOUT;
-		goto done;
-	}
-
-	mlx5_core_warn(dev, "Sync Reset, got reset action. rst_state = %u\n", rst_state);
-	if (rst_state == MLX5_FW_RST_STATE_TOGGLE_REQ) {
-		err = mlx5_sync_pci_reset(dev, fw_reset->reset_method);
-		if (err) {
-			mlx5_core_warn(dev, "mlx5_sync_pci_reset failed, err %d\n", err);
-			fw_reset->ret = err;
-		}
-	}
-
-done:
-	mlx5_fw_reset_complete_reload(dev, true);
+	mlx5_fw_reset_complete_reload(dev);
 }
 
 static void mlx5_sync_reset_abort_event(struct work_struct *work)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fw_reset.h b/drivers/net/ethernet/mellanox/mlx5/core/fw_reset.h
index ea527d06a85f..d5b28525c960 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/fw_reset.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/fw_reset.h
@@ -12,6 +12,7 @@ int mlx5_fw_reset_set_reset_sync(struct mlx5_core_dev *dev, u8 reset_type_sel,
 int mlx5_fw_reset_set_live_patch(struct mlx5_core_dev *dev);
 
 int mlx5_fw_reset_wait_reset_done(struct mlx5_core_dev *dev);
+void mlx5_sync_reset_unload_flow(struct mlx5_core_dev *dev, bool locked);
 int mlx5_fw_reset_verify_fw_complete(struct mlx5_core_dev *dev,
 				     struct netlink_ext_ack *extack);
 void mlx5_fw_reset_events_start(struct mlx5_core_dev *dev);
-- 
2.34.1

[PATCH net V2 07/11] net/mlx5: Nack sync reset when SFs are present

[Mark Bloch]

From: Moshe Shemesh <moshe@nvidia.com>

If PF (Physical Function) has SFs (Sub-Functions), since the SFs are not
taking part in the synchronization flow, sync reset can lead to fatal
error on the SFs, as the function will be closed unexpectedly from the
SF point of view.

Add a check to prevent sync reset when there are SFs on a PF device
which is not ECPF, as ECPF is teardowned gracefully before reset.

Fixes: 92501fa6e421 ("net/mlx5: Ack on sync_reset_request only if PF can do reset_now")
Signed-off-by: Moshe Shemesh <moshe@nvidia.com>
Reviewed-by: Parav Pandit <parav@nvidia.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Signed-off-by: Mark Bloch <mbloch@nvidia.com>
---
 drivers/net/ethernet/mellanox/mlx5/core/fw_reset.c   |  6 ++++++
 drivers/net/ethernet/mellanox/mlx5/core/sf/devlink.c | 10 ++++++++++
 drivers/net/ethernet/mellanox/mlx5/core/sf/sf.h      |  6 ++++++
 3 files changed, 22 insertions(+)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fw_reset.c b/drivers/net/ethernet/mellanox/mlx5/core/fw_reset.c
index 38b9b184ae01..22995131824a 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/fw_reset.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/fw_reset.c
@@ -6,6 +6,7 @@
 #include "fw_reset.h"
 #include "diag/fw_tracer.h"
 #include "lib/tout.h"
+#include "sf/sf.h"
 
 enum {
 	MLX5_FW_RESET_FLAGS_RESET_REQUESTED,
@@ -428,6 +429,11 @@ static bool mlx5_is_reset_now_capable(struct mlx5_core_dev *dev,
 		return false;
 	}
 
+	if (!mlx5_core_is_ecpf(dev) && !mlx5_sf_table_empty(dev)) {
+		mlx5_core_warn(dev, "SFs should be removed before reset\n");
+		return false;
+	}
+
 #if IS_ENABLED(CONFIG_HOTPLUG_PCI_PCIE)
 	if (reset_method != MLX5_MFRL_REG_PCI_RESET_METHOD_HOT_RESET) {
 		err = mlx5_check_hotplug_interrupt(dev, bridge);
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/sf/devlink.c b/drivers/net/ethernet/mellanox/mlx5/core/sf/devlink.c
index 0864ba625c07..3304f25cc805 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/sf/devlink.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/sf/devlink.c
@@ -518,3 +518,13 @@ void mlx5_sf_table_cleanup(struct mlx5_core_dev *dev)
 	WARN_ON(!xa_empty(&table->function_ids));
 	kfree(table);
 }
+
+bool mlx5_sf_table_empty(const struct mlx5_core_dev *dev)
+{
+	struct mlx5_sf_table *table = dev->priv.sf_table;
+
+	if (!table)
+		return true;
+
+	return xa_empty(&table->function_ids);
+}
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/sf/sf.h b/drivers/net/ethernet/mellanox/mlx5/core/sf/sf.h
index 860f9ddb7107..89559a37997a 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/sf/sf.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/sf/sf.h
@@ -17,6 +17,7 @@ void mlx5_sf_hw_table_destroy(struct mlx5_core_dev *dev);
 
 int mlx5_sf_table_init(struct mlx5_core_dev *dev);
 void mlx5_sf_table_cleanup(struct mlx5_core_dev *dev);
+bool mlx5_sf_table_empty(const struct mlx5_core_dev *dev);
 
 int mlx5_devlink_sf_port_new(struct devlink *devlink,
 			     const struct devlink_port_new_attrs *add_attr,
@@ -61,6 +62,11 @@ static inline void mlx5_sf_table_cleanup(struct mlx5_core_dev *dev)
 {
 }
 
+static inline bool mlx5_sf_table_empty(const struct mlx5_core_dev *dev)
+{
+	return true;
+}
+
 #endif
 
 #endif
-- 
2.34.1

[PATCH net V2 08/11] net/mlx5: Prevent flow steering mode changes in switchdev mode

[Mark Bloch]

From: Moshe Shemesh <moshe@nvidia.com>

Changing flow steering modes is not allowed when eswitch is in switchdev
mode. This fix ensures that any steering mode change, including to
firmware steering, is correctly blocked while eswitch mode is switchdev.

Fixes: e890acd5ff18 ("net/mlx5: Add devlink flow_steering_mode parameter")
Signed-off-by: Moshe Shemesh <moshe@nvidia.com>
Signed-off-by: Mark Bloch <mbloch@nvidia.com>
---
 drivers/net/ethernet/mellanox/mlx5/core/fs_core.c | 15 +++++++--------
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
index d87392360dbd..cb165085a4c1 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
@@ -3734,6 +3734,13 @@ static int mlx5_fs_mode_validate(struct devlink *devlink, u32 id,
 	char *value = val.vstr;
 	u8 eswitch_mode;
 
+	eswitch_mode = mlx5_eswitch_mode(dev);
+	if (eswitch_mode == MLX5_ESWITCH_OFFLOADS) {
+		NL_SET_ERR_MSG_FMT_MOD(extack,
+				       "Changing fs mode is not supported when eswitch offloads enabled.");
+		return -EOPNOTSUPP;
+	}
+
 	if (!strcmp(value, "dmfs"))
 		return 0;
 
@@ -3759,14 +3766,6 @@ static int mlx5_fs_mode_validate(struct devlink *devlink, u32 id,
 		return -EINVAL;
 	}
 
-	eswitch_mode = mlx5_eswitch_mode(dev);
-	if (eswitch_mode == MLX5_ESWITCH_OFFLOADS) {
-		NL_SET_ERR_MSG_FMT_MOD(extack,
-				       "Moving to %s is not supported when eswitch offloads enabled.",
-				       value);
-		return -EOPNOTSUPP;
-	}
-
 	return 0;
 }
 
-- 
2.34.1

[PATCH net V2 09/11] net/mlx5e: Update and set Xon/Xoff upon MTU set

[Mark Bloch]

From: Alexei Lazar <alazar@nvidia.com>

Xon/Xoff sizes are derived from calculation that include the MTU size.
Set Xon/Xoff when MTU is set.
If Xon/Xoff fails, set the previous MTU.

Fixes: 0696d60853d5 ("net/mlx5e: Receive buffer configuration")
Signed-off-by: Alexei Lazar <alazar@nvidia.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Signed-off-by: Mark Bloch <mbloch@nvidia.com>
---
 .../mellanox/mlx5/core/en/port_buffer.h         | 12 ++++++++++++
 .../net/ethernet/mellanox/mlx5/core/en_main.c   | 17 ++++++++++++++++-
 2 files changed, 28 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/port_buffer.h b/drivers/net/ethernet/mellanox/mlx5/core/en/port_buffer.h
index f4a19ffbb641..66d276a1be83 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en/port_buffer.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en/port_buffer.h
@@ -66,11 +66,23 @@ struct mlx5e_port_buffer {
 	struct mlx5e_bufferx_reg  buffer[MLX5E_MAX_NETWORK_BUFFER];
 };
 
+#ifdef CONFIG_MLX5_CORE_EN_DCB
 int mlx5e_port_manual_buffer_config(struct mlx5e_priv *priv,
 				    u32 change, unsigned int mtu,
 				    struct ieee_pfc *pfc,
 				    u32 *buffer_size,
 				    u8 *prio2buffer);
+#else
+static inline int
+mlx5e_port_manual_buffer_config(struct mlx5e_priv *priv,
+				u32 change, unsigned int mtu,
+				void *pfc,
+				u32 *buffer_size,
+				u8 *prio2buffer)
+{
+	return 0;
+}
+#endif
 
 int mlx5e_port_query_buffer(struct mlx5e_priv *priv,
 			    struct mlx5e_port_buffer *port_buffer);
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index 21bb88c5d3dc..15eded36b872 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -49,6 +49,7 @@
 #include "en.h"
 #include "en/dim.h"
 #include "en/txrx.h"
+#include "en/port_buffer.h"
 #include "en_tc.h"
 #include "en_rep.h"
 #include "en_accel/ipsec.h"
@@ -3040,9 +3041,11 @@ int mlx5e_set_dev_port_mtu(struct mlx5e_priv *priv)
 	struct mlx5e_params *params = &priv->channels.params;
 	struct net_device *netdev = priv->netdev;
 	struct mlx5_core_dev *mdev = priv->mdev;
-	u16 mtu;
+	u16 mtu, prev_mtu;
 	int err;
 
+	mlx5e_query_mtu(mdev, params, &prev_mtu);
+
 	err = mlx5e_set_mtu(mdev, params, params->sw_mtu);
 	if (err)
 		return err;
@@ -3052,6 +3055,18 @@ int mlx5e_set_dev_port_mtu(struct mlx5e_priv *priv)
 		netdev_warn(netdev, "%s: VPort MTU %d is different than netdev mtu %d\n",
 			    __func__, mtu, params->sw_mtu);
 
+	if (mtu != prev_mtu && MLX5_BUFFER_SUPPORTED(mdev)) {
+		err = mlx5e_port_manual_buffer_config(priv, 0, mtu,
+						      NULL, NULL, NULL);
+		if (err) {
+			netdev_warn(netdev, "%s: Failed to set Xon/Xoff values with MTU %d (err %d), setting back to previous MTU %d\n",
+				    __func__, mtu, err, prev_mtu);
+
+			mlx5e_set_mtu(mdev, params, prev_mtu);
+			return err;
+		}
+	}
+
 	params->sw_mtu = mtu;
 	return 0;
 }
-- 
2.34.1

[PATCH net V2 10/11] net/mlx5e: Update and set Xon/Xoff upon port speed set

[Mark Bloch]

From: Alexei Lazar <alazar@nvidia.com>

Xon/Xoff sizes are derived from calculations that include
the port speed.
These settings need to be updated and applied whenever the
port speed is changed.
The port speed is typically set after the physical link goes down
and is negotiated as part of the link-up process between the two
connected interfaces.
Xon/Xoff parameters being updated at the point where the new
negotiated speed is established.

Fixes: 0696d60853d5 ("net/mlx5e: Receive buffer configuration")
Signed-off-by: Alexei Lazar <alazar@nvidia.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Signed-off-by: Mark Bloch <mbloch@nvidia.com>
---
 drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index 15eded36b872..e680673ffb72 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -139,6 +139,8 @@ void mlx5e_update_carrier(struct mlx5e_priv *priv)
 	if (up) {
 		netdev_info(priv->netdev, "Link up\n");
 		netif_carrier_on(priv->netdev);
+		mlx5e_port_manual_buffer_config(priv, 0, priv->netdev->mtu,
+						NULL, NULL, NULL);
 	} else {
 		netdev_info(priv->netdev, "Link down\n");
 		netif_carrier_off(priv->netdev);
-- 
2.34.1

Re: [PATCH net V2 10/11] net/mlx5e: Update and set Xon/Xoff upon port speed set

[Jakub Kicinski]

On Mon, 25 Aug 2025 17:34:33 +0300 Mark Bloch wrote:
> Xon/Xoff sizes are derived from calculations that include
> the port speed.
> These settings need to be updated and applied whenever the
> port speed is changed.
> The port speed is typically set after the physical link goes down
> and is negotiated as part of the link-up process between the two
> connected interfaces.
> Xon/Xoff parameters being updated at the point where the new
> negotiated speed is established.

Hi, this is breaking dual host CX7 w/ 28.45.1300 (but I think most
older FW versions, too). Looks like the host is not receiving any
mcast (ping within a subnet doesn't work because the host receives
no ndisc), and most traffic slows down to a trickle.
Lost of rx_prio0_buf_discard increments.

Please TAL ASAP, this change went to LTS last week.

Re: [PATCH net V2 10/11] net/mlx5e: Update and set Xon/Xoff upon port speed set

[Jakub Kicinski]

On Wed, 10 Sep 2025 17:00:11 -0700 Jakub Kicinski wrote:
> On Mon, 25 Aug 2025 17:34:33 +0300 Mark Bloch wrote:
> > Xon/Xoff sizes are derived from calculations that include
> > the port speed.
> > These settings need to be updated and applied whenever the
> > port speed is changed.
> > The port speed is typically set after the physical link goes down
> > and is negotiated as part of the link-up process between the two
> > connected interfaces.
> > Xon/Xoff parameters being updated at the point where the new
> > negotiated speed is established.  
> 
> Hi, this is breaking dual host CX7 w/ 28.45.1300 (but I think most
> older FW versions, too). Looks like the host is not receiving any
> mcast (ping within a subnet doesn't work because the host receives
> no ndisc), and most traffic slows down to a trickle.
> Lost of rx_prio0_buf_discard increments.
> 
> Please TAL ASAP, this change went to LTS last week.

Any news on this? I heard that it also breaks DCB/QoS configuration
on 6.12.45 LTS.

Re: [PATCH net V2 10/11] net/mlx5e: Update and set Xon/Xoff upon port speed set

[Mark Bloch]

On 11/09/2025 16:47, Jakub Kicinski wrote:
> On Wed, 10 Sep 2025 17:00:11 -0700 Jakub Kicinski wrote:
>> On Mon, 25 Aug 2025 17:34:33 +0300 Mark Bloch wrote:
>>> Xon/Xoff sizes are derived from calculations that include
>>> the port speed.
>>> These settings need to be updated and applied whenever the
>>> port speed is changed.
>>> The port speed is typically set after the physical link goes down
>>> and is negotiated as part of the link-up process between the two
>>> connected interfaces.
>>> Xon/Xoff parameters being updated at the point where the new
>>> negotiated speed is established.  
>>
>> Hi, this is breaking dual host CX7 w/ 28.45.1300 (but I think most
>> older FW versions, too). Looks like the host is not receiving any
>> mcast (ping within a subnet doesn't work because the host receives
>> no ndisc), and most traffic slows down to a trickle.
>> Lost of rx_prio0_buf_discard increments.
>>
>> Please TAL ASAP, this change went to LTS last week.
> 
> Any news on this? I heard that it also breaks DCB/QoS configuration
> on 6.12.45 LTS.

Hi Jakub,

We are looking into this, once we have anything I'll update.
Just to make sure, reverting this is one commit solves the
issue you are seeing?

Mark

Re: [PATCH net V2 10/11] net/mlx5e: Update and set Xon/Xoff upon port speed set

[Jakub Kicinski]

On Thu, 11 Sep 2025 17:25:22 +0300 Mark Bloch wrote:
> On 11/09/2025 16:47, Jakub Kicinski wrote:
> > On Wed, 10 Sep 2025 17:00:11 -0700 Jakub Kicinski wrote:  
> >> Hi, this is breaking dual host CX7 w/ 28.45.1300 (but I think most
> >> older FW versions, too). Looks like the host is not receiving any
> >> mcast (ping within a subnet doesn't work because the host receives
> >> no ndisc), and most traffic slows down to a trickle.
> >> Lost of rx_prio0_buf_discard increments.
> >>
> >> Please TAL ASAP, this change went to LTS last week.  
> > 
> > Any news on this? I heard that it also breaks DCB/QoS configuration
> > on 6.12.45 LTS.  
> 
> We are looking into this, once we have anything I'll update.
> Just to make sure, reverting this is one commit solves the
> issue you are seeing?

It did for me, but Daniel (who is working on the PSP series)
mentioned that he had reverted all three to get net-next working:

  net/mlx5e: Set local Xoff after FW update
  net/mlx5e: Update and set Xon/Xoff upon port speed set
  net/mlx5e: Update and set Xon/Xoff upon MTU set

Re: [PATCH net V2 10/11] net/mlx5e: Update and set Xon/Xoff upon port speed set

[Tariq Toukan]

On 11/09/2025 17:36, Jakub Kicinski wrote:
> On Thu, 11 Sep 2025 17:25:22 +0300 Mark Bloch wrote:
>> On 11/09/2025 16:47, Jakub Kicinski wrote:
>>> On Wed, 10 Sep 2025 17:00:11 -0700 Jakub Kicinski wrote:
>>>> Hi, this is breaking dual host CX7 w/ 28.45.1300 (but I think most
>>>> older FW versions, too). Looks like the host is not receiving any
>>>> mcast (ping within a subnet doesn't work because the host receives
>>>> no ndisc), and most traffic slows down to a trickle.
>>>> Lost of rx_prio0_buf_discard increments.
>>>>
>>>> Please TAL ASAP, this change went to LTS last week.
>>>
>>> Any news on this? I heard that it also breaks DCB/QoS configuration
>>> on 6.12.45 LTS.
>>
>> We are looking into this, once we have anything I'll update.
>> Just to make sure, reverting this is one commit solves the
>> issue you are seeing?
> 
> It did for me, but Daniel (who is working on the PSP series)
> mentioned that he had reverted all three to get net-next working:
> 
>    net/mlx5e: Set local Xoff after FW update
>    net/mlx5e: Update and set Xon/Xoff upon port speed set
>    net/mlx5e: Update and set Xon/Xoff upon MTU set
> 

Hi Jakub,

Thanks for reporting.
We're investigating and will update soon.

Regards,
Tariq

Re: [PATCH net V2 10/11] net/mlx5e: Update and set Xon/Xoff upon port speed set

[Tariq Toukan]

On 15/09/2025 10:38, Tariq Toukan wrote:
> 
> 
> On 11/09/2025 17:36, Jakub Kicinski wrote:
>> On Thu, 11 Sep 2025 17:25:22 +0300 Mark Bloch wrote:
>>> On 11/09/2025 16:47, Jakub Kicinski wrote:
>>>> On Wed, 10 Sep 2025 17:00:11 -0700 Jakub Kicinski wrote:
>>>>> Hi, this is breaking dual host CX7 w/ 28.45.1300 (but I think most
>>>>> older FW versions, too). Looks like the host is not receiving any
>>>>> mcast (ping within a subnet doesn't work because the host receives
>>>>> no ndisc), and most traffic slows down to a trickle.
>>>>> Lost of rx_prio0_buf_discard increments.
>>>>>
>>>>> Please TAL ASAP, this change went to LTS last week.
>>>>
>>>> Any news on this? I heard that it also breaks DCB/QoS configuration
>>>> on 6.12.45 LTS.
>>>
>>> We are looking into this, once we have anything I'll update.
>>> Just to make sure, reverting this is one commit solves the
>>> issue you are seeing?
>>
>> It did for me, but Daniel (who is working on the PSP series)
>> mentioned that he had reverted all three to get net-next working:
>>
>>    net/mlx5e: Set local Xoff after FW update
>>    net/mlx5e: Update and set Xon/Xoff upon port speed set
>>    net/mlx5e: Update and set Xon/Xoff upon MTU set
>>
> 
> Hi Jakub,
> 
> Thanks for reporting.
> We're investigating and will update soon.
> 
> Regards,
> Tariq
> 

Hi,

We prefer reverting the single patch [1] for now. We'll submit a fixed 
version later.

Regarding the other two patches [2], initial testing showed no issues.
Can you/Daniel share more info? What issues you see, and the repro steps.

Thanks,
Tariq

[1]
net/mlx5e: Update and set Xon/Xoff upon port speed set

[2]
net/mlx5e: Set local Xoff after FW update
net/mlx5e: Update and set Xon/Xoff upon MTU set

Re: [PATCH net V2 10/11] net/mlx5e: Update and set Xon/Xoff upon port speed set

[Daniel Zahka]

On 9/17/25 6:39 AM, Tariq Toukan wrote:
>
>
> On 15/09/2025 10:38, Tariq Toukan wrote:
>>
>>
>> On 11/09/2025 17:36, Jakub Kicinski wrote:
>>> On Thu, 11 Sep 2025 17:25:22 +0300 Mark Bloch wrote:
>>>> On 11/09/2025 16:47, Jakub Kicinski wrote:
>>>>> On Wed, 10 Sep 2025 17:00:11 -0700 Jakub Kicinski wrote:
>>>>>> Hi, this is breaking dual host CX7 w/ 28.45.1300 (but I think most
>>>>>> older FW versions, too). Looks like the host is not receiving any
>>>>>> mcast (ping within a subnet doesn't work because the host receives
>>>>>> no ndisc), and most traffic slows down to a trickle.
>>>>>> Lost of rx_prio0_buf_discard increments.
>>>>>>
>>>>>> Please TAL ASAP, this change went to LTS last week.
>>>>>
>>>>> Any news on this? I heard that it also breaks DCB/QoS configuration
>>>>> on 6.12.45 LTS.
>>>>
>>>> We are looking into this, once we have anything I'll update.
>>>> Just to make sure, reverting this is one commit solves the
>>>> issue you are seeing?
>>>
>>> It did for me, but Daniel (who is working on the PSP series)
>>> mentioned that he had reverted all three to get net-next working:
>>>
>>>    net/mlx5e: Set local Xoff after FW update
>>>    net/mlx5e: Update and set Xon/Xoff upon port speed set
>>>    net/mlx5e: Update and set Xon/Xoff upon MTU set
>>>
>>
>> Hi Jakub,
>>
>> Thanks for reporting.
>> We're investigating and will update soon.
>>
>> Regards,
>> Tariq
>>
>
> Hi,
>
> We prefer reverting the single patch [1] for now. We'll submit a fixed 
> version later.
>
> Regarding the other two patches [2], initial testing showed no issues.
> Can you/Daniel share more info? What issues you see, and the repro steps.
>
> Thanks,
> Tariq
>
> [1]
> net/mlx5e: Update and set Xon/Xoff upon port speed set
>
> [2]
> net/mlx5e: Set local Xoff after FW update
> net/mlx5e: Update and set Xon/Xoff upon MTU set
>

Hello Tariq,

My notes for the situation were that I was running a vanilla net-next 
kernel on a dual host, CX7 system, with the 28.45.1300 FW at commit:

deb105f49879 net: phy: marvell: Fix 88e1510 downshift counter errata

and I was having the issues that Jakub described. No ping working in a 
subnet. Extremely slow bandwidth on a large transfer. My notes say that 
reverting just [1] (from your message) did not fix the problem, but then 
reverting [2] and [3] restored normal behavior.

However, I did attempt to reproduce again on the same system this 
morning, and now I'm seeing that reverting just [1] is sufficient to fix 
the issues.

Re: [PATCH net V2 10/11] net/mlx5e: Update and set Xon/Xoff upon port speed set

[Tariq Toukan]

On 17/09/2025 16:00, Daniel Zahka wrote:
> 
> 
> On 9/17/25 6:39 AM, Tariq Toukan wrote:
>>
>>
>> On 15/09/2025 10:38, Tariq Toukan wrote:
>>>
>>>
>>> On 11/09/2025 17:36, Jakub Kicinski wrote:
>>>> On Thu, 11 Sep 2025 17:25:22 +0300 Mark Bloch wrote:
>>>>> On 11/09/2025 16:47, Jakub Kicinski wrote:
>>>>>> On Wed, 10 Sep 2025 17:00:11 -0700 Jakub Kicinski wrote:
>>>>>>> Hi, this is breaking dual host CX7 w/ 28.45.1300 (but I think most
>>>>>>> older FW versions, too). Looks like the host is not receiving any
>>>>>>> mcast (ping within a subnet doesn't work because the host receives
>>>>>>> no ndisc), and most traffic slows down to a trickle.
>>>>>>> Lost of rx_prio0_buf_discard increments.
>>>>>>>
>>>>>>> Please TAL ASAP, this change went to LTS last week.
>>>>>>
>>>>>> Any news on this? I heard that it also breaks DCB/QoS configuration
>>>>>> on 6.12.45 LTS.
>>>>>
>>>>> We are looking into this, once we have anything I'll update.
>>>>> Just to make sure, reverting this is one commit solves the
>>>>> issue you are seeing?
>>>>
>>>> It did for me, but Daniel (who is working on the PSP series)
>>>> mentioned that he had reverted all three to get net-next working:
>>>>
>>>>    net/mlx5e: Set local Xoff after FW update
>>>>    net/mlx5e: Update and set Xon/Xoff upon port speed set
>>>>    net/mlx5e: Update and set Xon/Xoff upon MTU set
>>>>
>>>
>>> Hi Jakub,
>>>
>>> Thanks for reporting.
>>> We're investigating and will update soon.
>>>
>>> Regards,
>>> Tariq
>>>
>>
>> Hi,
>>
>> We prefer reverting the single patch [1] for now. We'll submit a fixed 
>> version later.
>>
>> Regarding the other two patches [2], initial testing showed no issues.
>> Can you/Daniel share more info? What issues you see, and the repro steps.
>>
>> Thanks,
>> Tariq
>>
>> [1]
>> net/mlx5e: Update and set Xon/Xoff upon port speed set
>>
>> [2]
>> net/mlx5e: Set local Xoff after FW update
>> net/mlx5e: Update and set Xon/Xoff upon MTU set
>>
> 
> Hello Tariq,
> 
> My notes for the situation were that I was running a vanilla net-next 
> kernel on a dual host, CX7 system, with the 28.45.1300 FW at commit:
> 
> deb105f49879 net: phy: marvell: Fix 88e1510 downshift counter errata
> 
> and I was having the issues that Jakub described. No ping working in a 
> subnet. Extremely slow bandwidth on a large transfer. My notes say that 
> reverting just [1] (from your message) did not fix the problem, but then 
> reverting [2] and [3] restored normal behavior.
> 
> However, I did attempt to reproduce again on the same system this 
> morning, and now I'm seeing that reverting just [1] is sufficient to fix 
> the issues.

I see.
For now, I'll submit a revert only for [1].

Let us know of any related issue you still hit after the revert.

Thanks.

[PATCH net V2 11/11] net/mlx5e: Set local Xoff after FW update

[Mark Bloch]

From: Alexei Lazar <alazar@nvidia.com>

The local Xoff value is being set before the firmware (FW) update.
In case of a failure where the FW is not updated with the new value,
there is no fallback to the previous value.
Update the local Xoff value after the FW has been successfully set.

Fixes: 0696d60853d5 ("net/mlx5e: Receive buffer configuration")
Signed-off-by: Alexei Lazar <alazar@nvidia.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com>
Signed-off-by: Mark Bloch <mbloch@nvidia.com>
---
 drivers/net/ethernet/mellanox/mlx5/core/en/port_buffer.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/port_buffer.c b/drivers/net/ethernet/mellanox/mlx5/core/en/port_buffer.c
index 3efa8bf1d14e..4720523813b9 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en/port_buffer.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en/port_buffer.c
@@ -575,7 +575,6 @@ int mlx5e_port_manual_buffer_config(struct mlx5e_priv *priv,
 		if (err)
 			return err;
 	}
-	priv->dcbx.xoff = xoff;
 
 	/* Apply the settings */
 	if (update_buffer) {
@@ -584,6 +583,8 @@ int mlx5e_port_manual_buffer_config(struct mlx5e_priv *priv,
 			return err;
 	}
 
+	priv->dcbx.xoff = xoff;
+
 	if (update_prio2buffer)
 		err = mlx5e_port_set_priority2buffer(priv->mdev, prio2buffer);
 
-- 
2.34.1

Re: [PATCH net V2 00/11] mlx5 misc fixes 2025-08-25

[patchwork-bot+netdevbpf]

Hello:

This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Mon, 25 Aug 2025 17:34:23 +0300 you wrote:
> Hi,
> 
> This patchset provides misc bug fixes from the team to the mlx5 core and
> Eth drivers.
> 
> V1: https://lore.kernel.org/all/20250824083944.523858-1-mbloch@nvidia.com/
> 
> [...]

Here is the summary with links:
  - [net,V2,01/11] net/mlx5: HWS, Fix memory leak in hws_pool_buddy_init error path
    https://git.kernel.org/netdev/net/c/2c0a959bebdc
  - [net,V2,02/11] net/mlx5: HWS, Fix memory leak in hws_action_get_shared_stc_nic error flow
    https://git.kernel.org/netdev/net/c/a630f83592cd
  - [net,V2,03/11] net/mlx5: HWS, Fix uninitialized variables in mlx5hws_pat_calc_nop error flow
    https://git.kernel.org/netdev/net/c/24b6e5314047
  - [net,V2,04/11] net/mlx5: HWS, Fix pattern destruction in mlx5hws_pat_get_pattern error path
    https://git.kernel.org/netdev/net/c/00a50e4e8974
  - [net,V2,05/11] net/mlx5: Reload auxiliary drivers on fw_activate
    https://git.kernel.org/netdev/net/c/34cc6a54914f
  - [net,V2,06/11] net/mlx5: Fix lockdep assertion on sync reset unload event
    https://git.kernel.org/netdev/net/c/902a8bc23a24
  - [net,V2,07/11] net/mlx5: Nack sync reset when SFs are present
    https://git.kernel.org/netdev/net/c/26e42ec7712d
  - [net,V2,08/11] net/mlx5: Prevent flow steering mode changes in switchdev mode
    https://git.kernel.org/netdev/net/c/cf9a8627b9a3
  - [net,V2,09/11] net/mlx5e: Update and set Xon/Xoff upon MTU set
    https://git.kernel.org/netdev/net/c/ceddedc969f0
  - [net,V2,10/11] net/mlx5e: Update and set Xon/Xoff upon port speed set
    https://git.kernel.org/netdev/net/c/d24341740fe4
  - [net,V2,11/11] net/mlx5e: Set local Xoff after FW update
    https://git.kernel.org/netdev/net/c/aca0c31af61e

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html