Linux RDMA and InfiniBand development
 help / color / mirror / Atom feed
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


             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