netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 0/8] mlxsw: Maintain candidate RIFs
Date: Thu, 22 Jun 2023 15:33:01 +0200	[thread overview]
Message-ID: <cover.1687438411.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.

The situation is going to be made better by implementing a range of replays
and post-hoc offloads.

This patch set lays the ground for replay of next hops. The particular
issue that it deals with is that currently, driver-specific bookkeeping for
next hops is hooked off RIF objects, which come and go across the lifetime
of a netdevice. We would rather keep these objects at an entity that
mirrors the lifetime of the netdevice itself. That way they are at hand and
can be offloaded when a RIF is eventually created.

To that end, with this patchset, mlxsw keeps a hash table of CRIFs:
candidate RIFs, persistent handles for netdevices that mlxsw deems
potentially interesting. The lifetime of a CRIF matches that of the
underlying netdevice, and thus a RIF can always assume a CRIF exists. A
CRIF is where next hops are kept, and when RIF is created, these next hops
can be easily offloaded. (Previously only the next hops created after the
RIF was created were offloaded.)

- Patches #1 and #2 are minor adjustments.
- In patches #3 and #4, add CRIF bookkeeping.
- In patch #5, link CRIFs to RIFs such that given a netdevice-backed RIF,
  the corresponding CRIF is easy to look up.
- Patch #6 is a clean-up allowed by the previous patches
- Patches #7 and #8 move next hop tracking to CRIFs

No observable effects are intended as of yet. This will be useful once
there is support for RIF creation for netdevices that become mlxsw uppers,
which will come in following patch sets.

Petr Machata (8):
  mlxsw: spectrum_router: Add extack argument to mlxsw_sp_lb_rif_init()
  mlxsw: spectrum_router: Use mlxsw_sp_ul_rif_get() to get main VRF LB
    RIF
  mlxsw: spectrum_router: Maintain a hash table of CRIFs
  mlxsw: spectrum_router: Maintain CRIF for fallback loopback RIF
  mlxsw: spectrum_router: Link CRIFs to RIFs
  mlxsw: spectrum_router: Use router.lb_crif instead of .lb_rif_index
  mlxsw: spectrum_router: Split nexthop finalization to two stages
  mlxsw: spectrum_router: Track next hops at CRIFs

 .../ethernet/mellanox/mlxsw/spectrum_router.c | 402 ++++++++++++++----
 .../ethernet/mellanox/mlxsw/spectrum_router.h |   3 +-
 2 files changed, 326 insertions(+), 79 deletions(-)

-- 
2.40.1


             reply	other threads:[~2023-06-22 13:33 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-22 13:33 Petr Machata [this message]
2023-06-22 13:33 ` [PATCH net-next 1/8] mlxsw: spectrum_router: Add extack argument to mlxsw_sp_lb_rif_init() Petr Machata
2023-06-22 13:33 ` [PATCH net-next 2/8] mlxsw: spectrum_router: Use mlxsw_sp_ul_rif_get() to get main VRF LB RIF Petr Machata
2023-06-22 13:33 ` [PATCH net-next 3/8] mlxsw: spectrum_router: Maintain a hash table of CRIFs Petr Machata
2023-06-22 13:33 ` [PATCH net-next 4/8] mlxsw: spectrum_router: Maintain CRIF for fallback loopback RIF Petr Machata
2023-06-22 13:33 ` [PATCH net-next 5/8] mlxsw: spectrum_router: Link CRIFs to RIFs Petr Machata
2023-06-22 13:33 ` [PATCH net-next 6/8] mlxsw: spectrum_router: Use router.lb_crif instead of .lb_rif_index Petr Machata
2023-06-22 13:33 ` [PATCH net-next 7/8] mlxsw: spectrum_router: Split nexthop finalization to two stages Petr Machata
2023-06-22 13:33 ` [PATCH net-next 8/8] mlxsw: spectrum_router: Track next hops at CRIFs Petr Machata
2023-06-24  2:10 ` [PATCH net-next 0/8] mlxsw: Maintain candidate RIFs 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.1687438411.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).