diff options
author | Jakub Kicinski <kuba@kernel.org> | 2024-08-13 03:50:36 +0300 |
---|---|---|
committer | Jakub Kicinski <kuba@kernel.org> | 2024-08-13 03:50:36 +0300 |
commit | e96f6fd30eec4ba6e2ff7f855f24b552c5853b06 (patch) | |
tree | bdac67c20b3de4cf6e7fc9a5755bf222b1cbd0d4 /drivers/net/ethernet/intel/ice/ice_parser.c | |
parent | 246ef40670b71fef0c3e2cd11404279bc6d6468e (diff) | |
parent | 4b808f44733243f981ae04046ef93a65ecc631a9 (diff) | |
download | linux-e96f6fd30eec4ba6e2ff7f855f24b552c5853b06.tar.xz |
Merge branch 'net-nexthop-increase-weight-to-u16'
Petr Machata says:
====================
net: nexthop: Increase weight to u16
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.
====================
Link: https://patch.msgid.link/cover.1723036486.git.petrm@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Diffstat (limited to 'drivers/net/ethernet/intel/ice/ice_parser.c')
0 files changed, 0 insertions, 0 deletions