From: Mark Bloch <mbloch@nvidia.com>
To: Bernardo Soares <bsoares.it@gmail.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>,
netdev@vger.kernel.org, saeedm@nvidia.com,
Vlad Buslov <vladbu@nvidia.com>
Subject: Re: [PATCH net v4 0/2] net/mlx5: Bridge, fix remaining switchdev ownership gaps on merged eswitch
Date: Tue, 22 Sep 2026 09:42:14 +0300 [thread overview]
Message-ID: <bc5c6362-e310-4b01-a033-c586660fe6b5@nvidia.com> (raw)
In-Reply-To: <20260918095931.29792-1-bsoares.it@gmail.com>
On 18/09/2026 12:59, Bernardo Soares wrote:
> 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.
>
For the series,
Reviewed-by: Mark Bloch <mbloch@nvidia.com>
Mark
> 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(-)
>
next prev parent reply other threads:[~2026-09-22 6:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-18 9:59 [PATCH net v4 0/2] net/mlx5: Bridge, fix remaining switchdev ownership gaps on merged eswitch Bernardo Soares
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 ` Mark Bloch [this message]
2026-09-23 1:20 ` [PATCH net v4 0/2] net/mlx5: Bridge, fix remaining switchdev ownership gaps on merged eswitch 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=bc5c6362-e310-4b01-a033-c586660fe6b5@nvidia.com \
--to=mbloch@nvidia.com \
--cc=bsoares.it@gmail.com \
--cc=daniel@iogearbox.net \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.