netdev - [PATCH net-next 00/10] mlxsw: Add support for resilient nexthop groups

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 24 Mar 2021 22:14:14 +0200
From:   Ido Schimmel <idosch@...sch.org>
To:     netdev@...r.kernel.org
Cc:     davem@...emloft.net, kuba@...nel.org, jiri@...dia.com,
        petrm@...dia.com, dsahern@...il.com, mlxsw@...dia.com,
        Ido Schimmel <idosch@...dia.com>
Subject: [PATCH net-next 00/10] mlxsw: Add support for resilient nexthop groups

From: Ido Schimmel <idosch@...dia.com>

This patchset adds support for resilient nexthop groups in mlxsw. As far
as the hardware is concerned, resilient groups are the same as regular
groups. The differences lie in how mlxsw manages the individual
adjacency entries (nexthop buckets) that make up the group.

The first difference is that unlike regular groups the driver needs to
periodically update the kernel about activity of nexthop buckets so that
the kernel will not treat the buckets as idle, given traffic is
offloaded from the CPU to the ASIC. This is similar to what mlxsw is
already doing with respect to neighbour entries. The update interval is
set to 1 second to allow for short idle timers.

The second difference is that nexthop buckets that correspond to an
unresolved neighbour must be programmed to the device, as the size of
the group must remain fixed. This is achieved by programming such
entries with trap action, in order to trigger neighbour resolution by
the kernel.

The third difference is atomic replacement of individual nexthop
buckets. While the driver periodically updates the kernel about activity
of nexthop buckets, it is possible for a bucket to become active just
before the kernel decides to replace it with a different nexthop. To
avoid such situations and connections being reset, the driver instructs
the device to only replace an adjacency entry if it is inactive.
Failures are propagated back to the nexthop code.

Patchset overview:

Patches #1-#7 gradually add support for resilient nexthop groups

Patch #8 finally enables such groups to be programmed to the device

Patches #9-#10 add mlxsw-specific selftests

Ido Schimmel (10):
  mlxsw: spectrum_router: Add support for resilient nexthop groups
  mlxsw: spectrum_router: Add ability to overwrite adjacency entry only
    when inactive
  mlxsw: spectrum_router: Pass payload pointer to nexthop update
    function
  mlxsw: spectrum_router: Add nexthop bucket replacement support
  mlxsw: spectrum_router: Update hardware flags on nexthop buckets
  mlxsw: reg: Add Router Adjacency Table Activity Dump Register
  mlxsw: spectrum_router: Periodically update activity of nexthop
    buckets
  mlxsw: spectrum_router: Enable resilient nexthop groups to be
    programmed
  selftests: mlxsw: Test unresolved neigh trap with resilient nexthop
    groups
  selftests: mlxsw: Add resilient nexthop groups configuration tests

 drivers/net/ethernet/mellanox/mlxsw/reg.h     |  55 +++
 .../ethernet/mellanox/mlxsw/spectrum_dpipe.c  |   4 +-
 .../ethernet/mellanox/mlxsw/spectrum_ipip.c   |  10 +-
 .../ethernet/mellanox/mlxsw/spectrum_ipip.h   |   3 +-
 .../ethernet/mellanox/mlxsw/spectrum_router.c | 422 +++++++++++++++++-
 .../ethernet/mellanox/mlxsw/spectrum_router.h |   5 +-
 .../net/mlxsw/devlink_trap_l3_exceptions.sh   |  31 ++
 .../selftests/drivers/net/mlxsw/rtnetlink.sh  |  82 ++++
 tools/testing/selftests/net/forwarding/lib.sh |   5 +
 9 files changed, 594 insertions(+), 23 deletions(-)

-- 
2.30.2