From: Tariq Toukan <tariqt@nvidia.com>
To: Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, <netdev@vger.kernel.org>,
Paolo Abeni <pabeni@redhat.com>
Cc: Adithya Jayachandran <ajayachandra@nvidia.com>,
Edward Srouji <edwards@nvidia.com>, Gal Pressman <gal@nvidia.com>,
Jason Gunthorpe <jgg@ziepe.ca>, Jiri Pirko <jiri@resnulli.us>,
Leon Romanovsky <leon@kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-rdma@vger.kernel.org>, Maher Sanalla <msanalla@nvidia.com>,
Mark Bloch <mbloch@nvidia.com>, Moshe Shemesh <moshe@nvidia.com>,
Or Har-Toov <ohartoov@nvidia.com>,
Saeed Mahameed <saeedm@nvidia.com>, Shay Drori <shayd@nvidia.com>,
Simon Horman <horms@kernel.org>, Tariq Toukan <tariqt@nvidia.com>
Subject: [PATCH net 0/3] net/mlx5: Preserve speed and state across vport modify commands
Date: Sun, 16 Aug 2026 09:50:12 +0300 [thread overview]
Message-ID: <20260816065015.3280733-1-tariqt@nvidia.com> (raw)
Hi,
The firmware vport modify command bundles both admin state and max tx
speed in a single operation, which requires each side to preserve the
other field when it only intends to change one.
When modifying max tx speed, the driver already queries the current
admin state and passes it back to avoid overwriting it. However, this
query and the subsequent modify were not atomic, a state change
between the two could cause the modify to overwrite the new state with
a stale value. The fix holds esw->state_lock across the query-modify
sequence.
When support for setting max tx speed via the vport modify command was
introduced, the existing admin state modify path was not updated to
preserve the current speed. As a result, the firmware interprets the
zero speed field as an intentional reset. The fix adds a speed query
before the state modify and passes the result back in the command.
To support that, mlx5_query_vport_max_tx_speed() had to be fixed first:
it was returning zero whenever the vport was DOWN, which was correct
for the query_port_speed verb but would defeat the purpose of querying
before a state modify. The DOWN-to-zero logic is moved to the
verb-layer caller so the function returns the raw firmware value.
Patch #1 holds esw->state_lock across the state query and modify in
the speed modify path
Patch #2 moves the vport DOWN zero mapping to the verb-layer caller
so the query returns the raw firmware value
Patch #3 queries current max tx speed before modifying vport state to
preserve it
Regards,
Tariq
Mark Bloch (1):
net/mlx5: E-Switch, use state lock for vport state changes
Or Har-Toov (2):
net/mlx5: Move vport DOWN state check out of
mlx5_query_vport_max_tx_speed()
net/mlx5: E-Switch, preserve max tx speed on vport state modification
drivers/infiniband/hw/mlx5/main.c | 5 ++-
.../net/ethernet/mellanox/mlx5/core/en_rep.c | 20 ++++++---
.../mellanox/mlx5/core/esw/adj_vport.c | 22 ++++++++++
.../mellanox/mlx5/core/eswitch_offloads.c | 4 ++
.../net/ethernet/mellanox/mlx5/core/lag/lag.c | 2 +
.../net/ethernet/mellanox/mlx5/core/vport.c | 44 +++++++++++++++----
include/linux/mlx5/vport.h | 3 +-
7 files changed, 84 insertions(+), 16 deletions(-)
base-commit: 24ef02f934eeb48830cff6b739abc3c62b1d107b
--
2.44.0
next reply other threads:[~2026-08-16 6:51 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-16 6:50 Tariq Toukan [this message]
2026-08-16 6:50 ` [PATCH net 1/3] net/mlx5: E-Switch, use state lock for vport state changes Tariq Toukan
2026-08-16 6:50 ` [PATCH net 2/3] net/mlx5: Move vport DOWN state check out of mlx5_query_vport_max_tx_speed() Tariq Toukan
2026-08-16 6:50 ` [PATCH net 3/3] net/mlx5: E-Switch, preserve max tx speed on vport state modification Tariq Toukan
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=20260816065015.3280733-1-tariqt@nvidia.com \
--to=tariqt@nvidia.com \
--cc=ajayachandra@nvidia.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=edwards@nvidia.com \
--cc=gal@nvidia.com \
--cc=horms@kernel.org \
--cc=jgg@ziepe.ca \
--cc=jiri@resnulli.us \
--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=moshe@nvidia.com \
--cc=msanalla@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