| Message ID | cover.1722519021.git.petrm@nvidia.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | net: nexthop: Increase weight to u16 | expand |
On Thu, 1 Aug 2024 18:23:56 +0200 Petr Machata wrote:
> Patches #3 to #6 add selftests.
Could you share the iproute2 patches?
Jakub Kicinski <kuba@kernel.org> writes: > On Thu, 1 Aug 2024 18:23:56 +0200 Petr Machata wrote: >> Patches #3 to #6 add selftests. > > Could you share the iproute2 patches? https://github.com/pmachata/iproute2/commits/nhgw16/
On 8/1/24 10:23 AM, Petr Machata wrote: > In CLOS networks, as link failures occur at various points in the network, > ECMP weights of the involved nodes are adjusted to compensate. With high > fan-out of the involved nodes, and overall high number of nodes, > a (non-)ECMP weight ratio that we would like to configure does not fit into > 8 bits. Instead of, say, 255:254, we might like to configure something like > 1000:999. For these deployments, the 8-bit weight may not be enough. > > To that end, in this patchset increase the next hop weight from u8 to u16. > > Patch #1 adds a flag that indicates whether the reserved fields are zeroed. > This is a follow-up to a new fix merged in commit 6d745cd0e972 ("net: > nexthop: Initialize all fields in dumped nexthops"). The theory behind this > patch is that there is a strict ordering between the fields actually being > zeroed, the kernel declaring that they are, and the kernel repurposing the > fields. Thus clients can use the flag to tell if it is safe to interpret > the reserved fields in any way. > > Patch #2 contains the substantial code and the commit message covers the > details of the changes. > > Patches #3 to #6 add selftests. > LGTM. For the set Reviewed-by: David Ahern <dsahern@kernel.org>
In CLOS networks, as link failures occur at various points in the network, ECMP weights of the involved nodes are adjusted to compensate. With high fan-out of the involved nodes, and overall high number of nodes, a (non-)ECMP weight ratio that we would like to configure does not fit into 8 bits. Instead of, say, 255:254, we might like to configure something like 1000:999. For these deployments, the 8-bit weight may not be enough. To that end, in this patchset increase the next hop weight from u8 to u16. Patch #1 adds a flag that indicates whether the reserved fields are zeroed. This is a follow-up to a new fix merged in commit 6d745cd0e972 ("net: nexthop: Initialize all fields in dumped nexthops"). The theory behind this patch is that there is a strict ordering between the fields actually being zeroed, the kernel declaring that they are, and the kernel repurposing the fields. Thus clients can use the flag to tell if it is safe to interpret the reserved fields in any way. Patch #2 contains the substantial code and the commit message covers the details of the changes. Patches #3 to #6 add selftests. Petr Machata (6): net: nexthop: Add flag to assert that NHGRP reserved fields are zero net: nexthop: Increase weight to u16 selftests: router_mpath: Sleep after MZ selftests: router_mpath_nh: Test 16-bit next hop weights selftests: router_mpath_nh_res: Test 16-bit next hop weights selftests: fib_nexthops: Test 16-bit next hop weights include/net/nexthop.h | 4 +- include/uapi/linux/nexthop.h | 10 +++- net/ipv4/nexthop.c | 49 ++++++++++------ tools/testing/selftests/net/fib_nexthops.sh | 55 +++++++++++++++++- tools/testing/selftests/net/forwarding/lib.sh | 7 +++ .../net/forwarding/router_mpath_nh.sh | 40 ++++++++++--- .../net/forwarding/router_mpath_nh_lib.sh | 13 +++++ .../net/forwarding/router_mpath_nh_res.sh | 58 ++++++++++++++++--- .../net/forwarding/router_multipath.sh | 2 + 9 files changed, 201 insertions(+), 37 deletions(-)