[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a4232f44-74df-48e2-81c2-75311f415002@kernel.org>
Date: Mon, 5 Aug 2024 08:31:20 -0600
From: David Ahern <dsahern@...nel.org>
To: Petr Machata <petrm@...dia.com>, "David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org
Cc: Ido Schimmel <idosch@...dia.com>, Donald Sharp <sharpd@...dia.com>,
mlxsw@...dia.com
Subject: Re: [PATCH net-next 0/6] net: nexthop: Increase weight to u16
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@...nel.org>
Powered by blists - more mailing lists