Netdev List
 help / color / mirror / Atom feed
From: Bernardo Soares <bsoares.it@gmail.com>
To: Mark Bloch <mbloch@nvidia.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>,
	netdev@vger.kernel.org, saeedm@nvidia.com,
	Vlad Buslov <vladbu@nvidia.com>,
	Bernardo Soares <bsoares.it@gmail.com>
Subject: [PATCH net v4 0/2] net/mlx5: Bridge, fix remaining switchdev ownership gaps on merged eswitch
Date: Fri, 18 Sep 2026 10:59:29 +0100	[thread overview]
Message-ID: <20260918095931.29792-1-bsoares.it@gmail.com> (raw)

v4 of "net/mlx5: Bridge, don't fail switchdev events of sibling
eswitch ports" (5f324c5d1b12), addressing reviewer feedback on v3:

 - The v3 commit message for patch 1 wrongly attributed the recursive
   lower-device walk fix to LAG bond enslavement order. As pointed
   out in review, mlx5_esw_bridge_lag_rep_get() already filters on
   mlx5_esw_bridge_dev_same_esw() per candidate and cannot select a
   sibling's rep. The actual bug is in the generic recursive walk
   used when attribute changes are emitted against the bridge master
   netdevice directly (a bridge with representors of more than one
   eswitch instance enslaved, no LAG involved): the walk returns as
   soon as any lower device yields a rep, and the underlying base
   case only checks same-HW, not ownership. Commit message rewritten
   to describe this correctly; no functional change from v3.
 - The v3 commit message for patch 2 claimed a "replayed/duplicate"
   NETDEV_CHANGEUPPER unlink as one of the reachable cases. As
   pointed out in review, netdevice notifiers are not replayed, so
   there is no such duplicate delivery. The actual (and only)
   reachable case is a sibling instance whose bridge offload notifier
   registers after a peer port was already enslaved, so it misses
   the link event and never tracks the port, then genuinely receives
   the later unlink event. Commit message rewritten accordingly; no
   functional change from v3.

Tested Patch 1 on a ConnectX-7 NIC (MT2910) on my single NIC system.
Patch 2 requires a multiple eswitch instance setup, so I wasn't able
to exercise its code paths.

Note: v1/v2 were sent From/Signed-off-by bersoare@isovalent.com; v3
and v4 are sent from my personal address (bsoares.it@gmail.com)
instead, for unrelated mail delivery reasons. Same author, same
person.

Bernardo Soares (2):
  net/mlx5: Bridge, don't fail switchdev events of sibling eswitch ports
  net/mlx5: Bridge, don't fail unlink of untracked/unsupported peer
    ports

 .../mellanox/mlx5/core/en/rep/bridge.c        | 45 +++++++++++++++----
 .../ethernet/mellanox/mlx5/core/esw/bridge.c  | 15 +++++--
 .../ethernet/mellanox/mlx5/core/esw/bridge.h  |  2 +
 3 files changed, 49 insertions(+), 13 deletions(-)

-- 
2.43.0


             reply	other threads:[~2026-09-18  9:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-18  9:59 Bernardo Soares [this message]
2026-09-18  9:59 ` [PATCH net v4 1/2] net/mlx5: Bridge, don't fail switchdev events of sibling eswitch ports Bernardo Soares
2026-09-22  6:52   ` Mark Bloch
2026-09-18  9:59 ` [PATCH net v4 2/2] net/mlx5: Bridge, don't fail unlink of untracked/unsupported peer ports Bernardo Soares
2026-09-22  6:52   ` Mark Bloch
2026-09-22  6:42 ` [PATCH net v4 0/2] net/mlx5: Bridge, fix remaining switchdev ownership gaps on merged eswitch Mark Bloch
2026-09-23  1:20 ` patchwork-bot+netdevbpf

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=20260918095931.29792-1-bsoares.it@gmail.com \
    --to=bsoares.it@gmail.com \
    --cc=daniel@iogearbox.net \
    --cc=mbloch@nvidia.com \
    --cc=netdev@vger.kernel.org \
    --cc=saeedm@nvidia.com \
    --cc=vladbu@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