From: Tariq Toukan <tariqt@nvidia.com>
To: Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@kernel.org>,
Jakub Kicinski <kuba@kernel.org>, <netdev@vger.kernel.org>,
Paolo Abeni <pabeni@redhat.com>
Cc: Gal Pressman <gal@nvidia.com>, Leon Romanovsky <leon@kernel.org>,
"open list" <linux-kernel@vger.kernel.org>,
<linux-rdma@vger.kernel.org>, Mark Bloch <mbloch@nvidia.com>,
Or Har-Toov <ohartoov@nvidia.com>,
Saeed Mahameed <saeedm@nvidia.com>, Shay Drory <shayd@nvidia.com>,
Tariq Toukan <tariqt@nvidia.com>
Subject: [PATCH net] net/mlx5: Lag, only cache max_tx_speed that FW has not accepted
Date: Sun, 4 Oct 2026 10:02:46 +0300 [thread overview]
Message-ID: <20261004070246.215239-1-tariqt@nvidia.com> (raw)
From: Or Har-Toov <ohartoov@nvidia.com>
vport->agg_max_tx_speed caches a max_tx_speed that could not be pushed
to FW, to be applied by mlx5_esw_vport_enable() once the vport comes up.
mlx5_lag_modify_device_vports_speed() also wrote it for enabled vports,
unconditionally, before even attempting the FW push. If that push
failed, the cache still claimed speed had been applied, even though FW
might still hold the old value. That unconfirmed value could then leak
out: mlx5_esw_vport_enable() replays it if the vport is later disabled
and re-enabled with no LAG update in between.
Write the cache only where FW does not hold the value: when the vport
is disabled and cannot be modified, and when the push itself failed.
Clear it once FW has accepted the value, so a superseded speed is not
replayed over a newer one. A vport whose push succeeded therefore keeps
no cached speed, and relies on FW retaining the programmed value.
This was raised in the AI review of v1 of "net/mlx5: Lag, reset vport
speed on teardown". It is unrelated to that patch, so it is fixed here
separately.
Link: https://lore.kernel.org/all/20260915015118.875210-1-kuba@kernel.org/
Fixes: c6df9a65cbb0 ("net/mlx5: Skip disabled vports when setting max TX speed")
Signed-off-by: Or Har-Toov <ohartoov@nvidia.com>
Reviewed-by: Mark Bloch <mbloch@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
---
drivers/net/ethernet/mellanox/mlx5/core/eswitch.c | 2 ++
drivers/net/ethernet/mellanox/mlx5/core/lag/lag.c | 12 ++++++++----
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
index fc197d1dc9df..f8c220bf7b5c 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
@@ -951,6 +951,8 @@ static void mlx5_esw_vport_set_max_tx_speed(struct mlx5_eswitch *esw,
mlx5_core_dbg(esw->dev,
"Failed to set vport %d speed %d, err=%d\n",
vport->vport, vport->agg_max_tx_speed, ret);
+ else
+ vport->agg_max_tx_speed = 0;
}
int mlx5_esw_vport_enable(struct mlx5_eswitch *esw, struct mlx5_vport *vport,
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/lag/lag.c b/drivers/net/ethernet/mellanox/mlx5/core/lag/lag.c
index 3b34bec559e0..7cee78cb47df 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/lag/lag.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/lag/lag.c
@@ -1502,17 +1502,21 @@ static void mlx5_lag_modify_device_vports_speed(struct mlx5_core_dev *mdev,
if (vport->vport == MLX5_VPORT_UPLINK)
continue;
- vport->agg_max_tx_speed = speed;
-
- if (!vport->enabled)
+ if (!vport->enabled) {
+ vport->agg_max_tx_speed = speed;
continue;
+ }
ret = mlx5_modify_vport_max_tx_speed(mdev, op_mod,
vport->vport, true, speed);
- if (ret)
+ if (ret) {
mlx5_core_dbg(mdev,
"Failed to set vport %d speed %d, err=%d\n",
vport->vport, speed, ret);
+ vport->agg_max_tx_speed = speed;
+ } else {
+ vport->agg_max_tx_speed = 0;
+ }
}
mutex_unlock(&esw->state_lock);
}
base-commit: 6dc989ea46b96ce170840174b4a38c4a387fb005
--
2.44.0
next reply other threads:[~2026-10-04 7:03 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-04 7:02 Tariq Toukan [this message]
2026-10-04 7:08 ` netdev-bot+sinfo
2026-10-05 7:42 ` netdev-bot+sashiko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261004070246.215239-1-tariqt@nvidia.com \
--to=tariqt@nvidia.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=gal@nvidia.com \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=mbloch@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=ohartoov@nvidia.com \
--cc=pabeni@redhat.com \
--cc=saeedm@nvidia.com \
--cc=shayd@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®