From: Petr Machata <petrm@nvidia.com>
To: <netdev@vger.kernel.org>
Cc: Ido Schimmel <idosch@nvidia.com>,
David Ahern <dsahern@kernel.org>,
"David S . Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
"Petr Machata" <petrm@nvidia.com>
Subject: [PATCH net-next 00/10] net: Resilient NH groups: netdevsim, selftests
Date: Fri, 12 Mar 2021 17:50:16 +0100 [thread overview]
Message-ID: <cover.1615563035.git.petrm@nvidia.com> (raw)
Support for resilient next-hop groups was added in a previous patch set.
Resilient next hop groups add a layer of indirection between the SKB hash
and the next hop. Thus the hash is used to reference a hash table bucket,
which is then used to reference a particular next hop. This allows the
system more flexibility when assigning SKB hash space to next hops.
Previously, each next hop had to be assigned a continuous range of SKB hash
space. With a hash table as an intermediate layer, it is possible to
reassign next hops with a hash table bucket granularity. In turn, this
mends issues with traffic flow redirection resulting from next hop removal
or adjustments in next-hop weights.
This patch set introduces mock offloading of resilient next hop groups by
the netdevsim driver, and a suite of selftests.
- Patch #1 adds a netdevsim-specific lock to protect next-hop hashtable.
Previously, netdevsim relied on RTNL to maintain mutual exclusion.
Patch #2 extracts a helper to make the following patches clearer.
- Patch #3 implements the support for offloading of resilient next-hop
groups.
- Patch #4 introduces a new debugfs interface to set activity on a selected
next-hop bucket. This simulates how HW can periodically report bucket
activity, and buckets thus marked are expected to be exempt from
migration to new next hops when the group changes.
- Patches #5 and #6 clean up the fib_nexthop selftests.
- Patches #7, #8 and #9 add tests for resilient next hop groups. Patch #7
adds resilient-hashing counterparts to fib_nexthops.sh. Patch #8 adds a
new traffic test for resilient next-hop groups. Patch #9 adds a new
traffic test for tunneling.
- Patch #10 actually leverages the netdevsim offload to implement a suite
of algorithmic tests that verify how and when buckets are migrated under
various simulated workload scenarios.
The overall plan is to contribute approximately the following patchsets:
1) Nexthop policy refactoring (already pushed)
2) Preparations for resilient next hop groups (already pushed)
3) Implementation of resilient next hop group (already pushed)
4) Netdevsim offload plus a suite of selftests (this patchset)
5) Preparations for mlxsw offload of resilient next-hop groups
6) mlxsw offload including selftests
Interested parties can look at the complete code at [2].
[1] https://tools.ietf.org/html/rfc2992
[2] https://github.com/idosch/linux/commits/submit/res_integ_v1
Ido Schimmel (9):
netdevsim: Create a helper for setting nexthop hardware flags
netdevsim: Add support for resilient nexthop groups
netdevsim: Allow reporting activity on nexthop buckets
selftests: fib_nexthops: Declutter test output
selftests: fib_nexthops: List each test case in a different line
selftests: fib_nexthops: Test resilient nexthop groups
selftests: forwarding: Add resilient hashing test
selftests: forwarding: Add resilient multipath tunneling nexthop test
selftests: netdevsim: Add test for resilient nexthop groups offload
API
Petr Machata (1):
netdevsim: fib: Introduce a lock to guard nexthop hashtable
drivers/net/netdevsim/fib.c | 139 +++-
.../drivers/net/netdevsim/nexthop.sh | 620 ++++++++++++++++++
tools/testing/selftests/net/fib_nexthops.sh | 549 +++++++++++++++-
.../net/forwarding/gre_multipath_nh_res.sh | 361 ++++++++++
.../net/forwarding/router_mpath_nh_res.sh | 400 +++++++++++
5 files changed, 2059 insertions(+), 10 deletions(-)
create mode 100755 tools/testing/selftests/net/forwarding/gre_multipath_nh_res.sh
create mode 100755 tools/testing/selftests/net/forwarding/router_mpath_nh_res.sh
--
2.26.2
next reply other threads:[~2021-03-12 16:52 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-12 16:50 Petr Machata [this message]
2021-03-12 16:50 ` [PATCH net-next 01/10] netdevsim: fib: Introduce a lock to guard nexthop hashtable Petr Machata
2021-03-12 16:50 ` [PATCH net-next 02/10] netdevsim: Create a helper for setting nexthop hardware flags Petr Machata
2021-03-12 16:50 ` [PATCH net-next 03/10] netdevsim: Add support for resilient nexthop groups Petr Machata
2021-03-12 16:50 ` [PATCH net-next 04/10] netdevsim: Allow reporting activity on nexthop buckets Petr Machata
2021-03-12 16:50 ` [PATCH net-next 05/10] selftests: fib_nexthops: Declutter test output Petr Machata
2021-03-14 15:29 ` David Ahern
2021-03-12 16:50 ` [PATCH net-next 06/10] selftests: fib_nexthops: List each test case in a different line Petr Machata
2021-03-14 15:30 ` David Ahern
2021-03-12 16:50 ` [PATCH net-next 07/10] selftests: fib_nexthops: Test resilient nexthop groups Petr Machata
2021-03-14 15:42 ` David Ahern
2021-03-12 16:50 ` [PATCH net-next 08/10] selftests: forwarding: Add resilient hashing test Petr Machata
2021-03-12 16:50 ` [PATCH net-next 09/10] selftests: forwarding: Add resilient multipath tunneling nexthop test Petr Machata
2021-03-12 16:50 ` [PATCH net-next 10/10] selftests: netdevsim: Add test for resilient nexthop groups offload API Petr Machata
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.1615563035.git.petrm@nvidia.com \
--to=petrm@nvidia.com \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=idosch@nvidia.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
/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.