From: Petr Machata <petrm@nvidia.com>
To: "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
<netdev@vger.kernel.org>
Cc: Ido Schimmel <idosch@nvidia.com>, Petr Machata <petrm@nvidia.com>,
Danielle Ratson <danieller@nvidia.com>, <mlxsw@nvidia.com>
Subject: [PATCH net-next 00/17] mlxsw: Permit enslavement to netdevices with uppers
Date: Wed, 19 Jul 2023 13:01:15 +0200 [thread overview]
Message-ID: <cover.1689763088.git.petrm@nvidia.com> (raw)
The mlxsw driver currently makes the assumption that the user applies
configuration in a bottom-up manner. Thus netdevices need to be added to
the bridge before IP addresses are configured on that bridge or SVI added
on top of it. Enslaving a netdevice to another netdevice that already has
uppers is in fact forbidden by mlxsw for this reason. Despite this safety,
it is rather easy to get into situations where the offloaded configuration
is just plain wrong.
As an example, take a front panel port, configure an IP address: it gets a
RIF. Now enslave the port to the bridge, and the RIF is gone. Remove the
port from the bridge again, but the RIF never comes back. There is a number
of similar situations, where changing the configuration there and back
utterly breaks the offload.
Similarly, detaching a front panel port from a configured topology means
unoffloading of this whole topology -- VLAN uppers, next hops, etc.
Attaching the port back is then not permitted at all. If it were, it would
not result in a working configuration, because much of mlxsw is written to
react to changes in immediate configuration. There is nothing that would go
visit netdevices in the attached-to topology and offload existing routes
and VLAN memberships, for example.
In this patchset, introduce a number of replays to be invoked so that this
sort of post-hoc offload is supported. Then remove the vetoes that
disallowed enslavement of front panel ports to other netdevices with
uppers.
The patchset progresses as follows:
- In patch #1, fix an issue in the bridge driver. To my knowledge, the
issue could not have resulted in a buggy behavior previously, and thus is
packaged with this patchset instead of being sent separately to net.
- In patch #2, add a new helper to the switchdev code.
- In patch #3, drop mlxsw selftests that will not be relevant after this
patchset anymore.
- Patches #4, #5, #6, #7 and #8 prepare the codebase for smoother
introduction of the rest of the code.
- Patches #9, #10, #11, #12, #13 and #14 replay various aspects of upper
configuration when a front panel port is introduced into a topology.
Individual patches take care of bridge and LAG RIF memberships, switchdev
replay, nexthop and neighbors replay, and MACVLAN offload.
- Patches #15 and #16 introduce RIFs for newly-relevant netdevices when a
front panel port is enslaved (in which case all uppers are newly
relevant), or, respectively, deslaved (in which case the newly-relevant
netdevice is the one being deslaved).
- Up until this point, the introduced scaffolding was not really used,
because mlxsw still forbids enslavement of mlxsw netdevices to uppers
with uppers. In patch #17, this condition is finally relaxed.
A sizable selftest suite is available to test all this new code. That will
be sent in a separate patchset.
Petr Machata (17):
net: bridge: br_switchdev: Tolerate -EOPNOTSUPP when replaying MDB
net: switchdev: Add a helper to replay objects on a bridge port
selftests: mlxsw: rtnetlink: Drop obsolete tests
mlxsw: spectrum_router: Allow address handlers to run on bridge ports
mlxsw: spectrum_router: Extract a helper to schedule neighbour work
mlxsw: spectrum: Split a helper out of mlxsw_sp_netdevice_event()
mlxsw: spectrum: Allow event handlers to check unowned bridges
mlxsw: spectrum: Add a replay_deslavement argument to event handlers
mlxsw: spectrum: On port enslavement to a LAG, join upper's bridges
mlxsw: spectrum_switchdev: Replay switchdev objects on port join
mlxsw: spectrum_router: Join RIFs of LAG upper VLANs
mlxsw: spectrum_router: Offload ethernet nexthops when RIF is made
mlxsw: spectrum_router: Replay MACVLANs when RIF is made
mlxsw: spectrum_router: Replay neighbours when RIF is made
mlxsw: spectrum_router: Replay IP NETDEV_UP on device enslavement
mlxsw: spectrum_router: Replay IP NETDEV_UP on device deslavement
mlxsw: spectrum: Permit enslavement to netdevices with uppers
.../net/ethernet/mellanox/mlxsw/spectrum.c | 312 ++++++++++---
.../net/ethernet/mellanox/mlxsw/spectrum.h | 2 +
.../ethernet/mellanox/mlxsw/spectrum_router.c | 432 ++++++++++++++++--
.../ethernet/mellanox/mlxsw/spectrum_router.h | 7 +
.../mellanox/mlxsw/spectrum_switchdev.c | 138 +++++-
include/net/switchdev.h | 6 +
net/bridge/br.c | 8 +
net/bridge/br_private.h | 16 +
net/bridge/br_switchdev.c | 15 +-
net/switchdev/switchdev.c | 25 +
.../selftests/drivers/net/mlxsw/rtnetlink.sh | 31 --
11 files changed, 862 insertions(+), 130 deletions(-)
--
2.40.1
next reply other threads:[~2023-07-19 11:02 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-19 11:01 Petr Machata [this message]
2023-07-19 11:01 ` [PATCH net-next 01/17] net: bridge: br_switchdev: Tolerate -EOPNOTSUPP when replaying MDB Petr Machata
2023-07-19 11:01 ` [PATCH net-next 02/17] net: switchdev: Add a helper to replay objects on a bridge port Petr Machata
2024-01-31 15:47 ` Vladimir Oltean
2023-07-19 11:01 ` [PATCH net-next 03/17] selftests: mlxsw: rtnetlink: Drop obsolete tests Petr Machata
2023-07-19 11:01 ` [PATCH net-next 04/17] mlxsw: spectrum_router: Allow address handlers to run on bridge ports Petr Machata
2023-07-19 11:01 ` [PATCH net-next 05/17] mlxsw: spectrum_router: Extract a helper to schedule neighbour work Petr Machata
2023-07-19 11:01 ` [PATCH net-next 06/17] mlxsw: spectrum: Split a helper out of mlxsw_sp_netdevice_event() Petr Machata
2023-07-19 11:01 ` [PATCH net-next 07/17] mlxsw: spectrum: Allow event handlers to check unowned bridges Petr Machata
2023-07-19 11:01 ` [PATCH net-next 08/17] mlxsw: spectrum: Add a replay_deslavement argument to event handlers Petr Machata
2023-07-19 11:01 ` [PATCH net-next 09/17] mlxsw: spectrum: On port enslavement to a LAG, join upper's bridges Petr Machata
2023-07-19 11:01 ` [PATCH net-next 10/17] mlxsw: spectrum_switchdev: Replay switchdev objects on port join Petr Machata
2023-07-19 11:01 ` [PATCH net-next 11/17] mlxsw: spectrum_router: Join RIFs of LAG upper VLANs Petr Machata
2023-07-19 11:01 ` [PATCH net-next 12/17] mlxsw: spectrum_router: Offload ethernet nexthops when RIF is made Petr Machata
2023-07-19 11:01 ` [PATCH net-next 13/17] mlxsw: spectrum_router: Replay MACVLANs " Petr Machata
2023-07-19 11:01 ` [PATCH net-next 14/17] mlxsw: spectrum_router: Replay neighbours " Petr Machata
2023-07-19 11:01 ` [PATCH net-next 15/17] mlxsw: spectrum_router: Replay IP NETDEV_UP on device enslavement Petr Machata
2023-07-19 11:01 ` [PATCH net-next 16/17] mlxsw: spectrum_router: Replay IP NETDEV_UP on device deslavement Petr Machata
2023-07-19 11:01 ` [PATCH net-next 17/17] mlxsw: spectrum: Permit enslavement to netdevices with uppers Petr Machata
2023-07-21 8:10 ` [PATCH net-next 00/17] mlxsw: " 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=cover.1689763088.git.petrm@nvidia.com \
--to=petrm@nvidia.com \
--cc=danieller@nvidia.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=idosch@nvidia.com \
--cc=kuba@kernel.org \
--cc=mlxsw@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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;
as well as URLs for NNTP newsgroup(s).