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: Edward Srouji <edwards@nvidia.com>, Gal Pressman <gal@nvidia.com>,
"Jason Gunthorpe" <jgg@ziepe.ca>,
Leon Romanovsky <leon@kernel.org>,
open list <linux-kernel@vger.kernel.org>,
<linux-rdma@vger.kernel.org>, Maher Sanalla <msanalla@nvidia.com>,
Mark Bloch <mbloch@nvidia.com>, Or Har-Toov <ohartoov@nvidia.com>,
Saeed Mahameed <saeedm@nvidia.com>, Shay Drori <shayd@nvidia.com>,
Tariq Toukan <tariqt@nvidia.com>
Subject: [PATCH net 0/5] net/mlx5: fixes for LAG max_tx_speed update flow
Date: Thu, 10 Sep 2026 13:24:27 +0300 [thread overview]
Message-ID: <20260910102432.3845360-1-tariqt@nvidia.com> (raw)
Hi,
Commit 50f1d188c580 ("net/mlx5: Propagate LAG effective max_tx_speed to
vports") added a mechanism that computes the aggregated LAG TX speed and
programs it into each vport's max_tx_speed via MODIFY_VPORT_STATE. This
series by Or fixes bugs found in that flow.
The bugs:
1. Down ports were counted into the effective aggregate speed.
When a port goes down, PTYS eth_proto_oper is not necessary 0.
2. The aggregate was not limited by the NIC's PCIe bandwidth. It was
taken from the bond speed, which is calculated from PTYS, and PTYS
is not bounded by the PCI bandwidth of the NIC. FW initializes
max_tx_speed to the minimum of the port speed and the PCIe
bandwidth, so modifying it with a value computed by different rules
changes the meaning of the field rather than updating it.
3. MPESW teardown never reset the vport speeds, leaving stale values
after teardown.
4. RoCE LAG never told the RDMA layer about speed changes. The NIC is
considered to be in a bare metal configuration, without a valid or
enabled eswitch, so there are no VF, SF or PF rep vports to modify
and no event of speed change was raised.
Patch #1 splits the LAG aggregate speed into an operative and a max
helper, so that each can filter on port state on its own.
Patch #2 resets the vport speed on MPESW teardown.
Patch #3 caches the TX-enabled aggregate speed and programs that into
the vports, instead of reading it back from the bond netdev.
Patch #4 limits the aggregated TX speed by the NIC's PCIe bandwidth.
Patch #5 notifies the RDMA layer of RoCE LAG speed changes via a new
driver event.
Regards,
Tariq
Or Har-Toov (5):
net/mlx5: Lag, split aggregate speed into oper and max helpers
net/mlx5: Lag, reset vport speed on teardown
{RDMA,net}/mlx5: cache and use TX-enabled aggregate speed for vports
net/mlx5: Lag, limit aggregated TX speed by PCIe bandwidth
{RDMA,net}/mlx5: notify RoCE LAG speed change via driver event
drivers/infiniband/hw/mlx5/main.c | 12 +-
drivers/net/ethernet/mellanox/mlx5/core/dev.c | 20 +++
.../net/ethernet/mellanox/mlx5/core/lag/lag.c | 159 +++++++++++++++---
.../net/ethernet/mellanox/mlx5/core/lag/lag.h | 16 +-
.../ethernet/mellanox/mlx5/core/mlx5_core.h | 1 +
include/linux/mlx5/device.h | 1 +
include/linux/mlx5/driver.h | 1 +
7 files changed, 181 insertions(+), 29 deletions(-)
base-commit: 00f9fbc12320253bfc576fb7539d860029c82d0f
--
2.44.0
next reply other threads:[~2026-09-10 10:25 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-10 10:24 Tariq Toukan [this message]
2026-09-10 10:24 ` [PATCH net 1/5] net/mlx5: Lag, split aggregate speed into oper and max helpers Tariq Toukan
2026-09-15 1:51 ` Jakub Kicinski
2026-09-10 10:24 ` [PATCH net 2/5] net/mlx5: Lag, reset vport speed on teardown Tariq Toukan
2026-09-15 1:51 ` Jakub Kicinski
2026-09-10 10:24 ` [PATCH net 3/5] {RDMA,net}/mlx5: cache and use TX-enabled aggregate speed for vports Tariq Toukan
2026-09-15 1:51 ` Jakub Kicinski
2026-09-10 10:24 ` [PATCH net 4/5] net/mlx5: Lag, limit aggregated TX speed by PCIe bandwidth Tariq Toukan
2026-09-15 1:51 ` Jakub Kicinski
2026-09-10 10:24 ` [PATCH net 5/5] {RDMA,net}/mlx5: notify RoCE LAG speed change via driver event Tariq Toukan
2026-09-15 1:51 ` Jakub Kicinski
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=20260910102432.3845360-1-tariqt@nvidia.com \
--to=tariqt@nvidia.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=edwards@nvidia.com \
--cc=gal@nvidia.com \
--cc=jgg@ziepe.ca \
--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=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
all inboxes | Powered by JetHome®