All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Machata <petrm@nvidia.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Petr Machata <petrm@nvidia.com>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Paolo Abeni <pabeni@redhat.com>, <netdev@vger.kernel.org>,
	Ido Schimmel <idosch@nvidia.com>,
	David Ahern <dsahern@kernel.org>,
	Donald Sharp <sharpd@nvidia.com>, Simon Horman <horms@kernel.org>,
	Przemek Kitszel <przemyslaw.kitszel@intel.com>,
	<mlxsw@nvidia.com>
Subject: Re: [PATCH net-next v2 0/6] net: nexthop: Increase weight to u16
Date: Fri, 9 Aug 2024 11:48:09 +0200	[thread overview]
Message-ID: <87o762m31v.fsf@nvidia.com> (raw)
In-Reply-To: <20240808062847.4eb13f28@kernel.org>


Jakub Kicinski <kuba@kernel.org> writes:

> On Wed, 7 Aug 2024 16:13:45 +0200 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.
>
> I did update iproute2 to the branch you sent me last time, but tests
> are not happy:
>
> # IPv6 groups functional
> # ----------------------
> # TEST: Create nexthop group with single nexthop                      [ OK ]
> # TEST: Get nexthop group by id                                       [ OK ]
> # TEST: Delete nexthop group by id                                    [ OK ]
> # TEST: Nexthop group with multiple nexthops                          [ OK ]
> # TEST: Nexthop group updated when entry is deleted                   [ OK ]
> # TEST: Nexthop group with weighted nexthops                          [ OK ]
> # TEST: Weighted nexthop group updated when entry is deleted          [ OK ]
> # TEST: Nexthops in groups removed on admin down                      [ OK ]
> # TEST: Multiple groups with same nexthop                             [ OK ]
> # TEST: Nexthops in group removed on admin down - mixed group         [ OK ]
> # TEST: Nexthop group can not have a group as an entry                [ OK ]
> # TEST: Nexthop group with a blackhole entry                          [ OK ]
> # TEST: Nexthop group can not have a blackhole and another nexthop    [ OK ]
> # TEST: Nexthop group replace refcounts                               [ OK ]
> #       WARNING: Unexpected route entry
> # TEST: 16-bit weights                                                [FAIL]
> # 
> # IPv6 resilient groups functional
> # --------------------------------
> # TEST: Nexthop group updated when entry is deleted                   [ OK ]
> # TEST: Nexthop buckets updated when entry is deleted                 [ OK ]
> # TEST: Nexthop group updated after replace                           [ OK ]
> # TEST: Nexthop buckets updated after replace                         [ OK ]
> # TEST: Nexthop group updated when entry is deleted - nECMP           [ OK ]
> # TEST: Nexthop buckets updated when entry is deleted - nECMP         [ OK ]
> # TEST: Nexthop group updated after replace - nECMP                   [ OK ]
> # TEST: Nexthop buckets updated after replace - nECMP                 [ OK ]
> #       WARNING: Unexpected route entry
> # TEST: 16-bit weights                                                [FAIL]
>
> https://netdev-3.bots.linux.dev/vmksft-net/results/718641/2-fib-nexthops-sh/stdout

This failure mode is consistent with non-updated iproute2. I only pushed
to the iproute2 repository after having sent the kernel patches, so I
think you or your automation have picked up the old version. Can you try
again, please? I retested on my end and it still works.

  reply	other threads:[~2024-08-09  9:58 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-07 14:13 [PATCH net-next v2 0/6] net: nexthop: Increase weight to u16 Petr Machata
2024-08-07 14:13 ` [PATCH net-next v2 1/6] net: nexthop: Add flag to assert that NHGRP reserved fields are zero Petr Machata
2024-08-08  7:13   ` Ido Schimmel
2024-08-07 14:13 ` [PATCH net-next v2 2/6] net: nexthop: Increase weight to u16 Petr Machata
2024-08-07 14:13 ` [PATCH net-next v2 3/6] selftests: router_mpath: Sleep after MZ Petr Machata
2024-08-07 14:13 ` [PATCH net-next v2 4/6] selftests: router_mpath_nh: Test 16-bit next hop weights Petr Machata
2024-08-07 14:13 ` [PATCH net-next v2 5/6] selftests: router_mpath_nh_res: " Petr Machata
2024-08-07 14:13 ` [PATCH net-next v2 6/6] selftests: fib_nexthops: " Petr Machata
2024-08-08 13:28 ` [PATCH net-next v2 0/6] net: nexthop: Increase weight to u16 Jakub Kicinski
2024-08-09  9:48   ` Petr Machata [this message]
2024-08-10  4:09     ` Jakub Kicinski
2024-08-12 10:09       ` Petr Machata
2024-08-13  1:00 ` patchwork-bot+netdevbpf

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=87o762m31v.fsf@nvidia.com \
    --to=petrm@nvidia.com \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=idosch@nvidia.com \
    --cc=kuba@kernel.org \
    --cc=mlxsw@nvidia.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=przemyslaw.kitszel@intel.com \
    --cc=sharpd@nvidia.com \
    /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.