From: Jakub Kicinski <kuba@kernel.org>
To: Neil Spring <ntspring@meta.com>
Cc: netdev@vger.kernel.org, edumazet@google.com,
ncardwell@google.com, kuniyu@google.com, davem@davemloft.net,
dsahern@kernel.org, pabeni@redhat.com, horms@kernel.org,
shuah@kernel.org, linux-kselftest@vger.kernel.org
Subject: Re: [PATCH net-next v5 2/2] selftests: net: add local ECMP rehash test
Date: Sat, 16 May 2026 10:44:16 -0700 [thread overview]
Message-ID: <20260516104416.09aa5458@kernel.org> (raw)
In-Reply-To: <20260513204048.2721843-3-ntspring@meta.com>
On Wed, 13 May 2026 13:40:48 -0700 Neil Spring wrote:
> Add ecmp_rehash.sh with nine scenarios verifying that TCP rehash
> selects a different local ECMP path for IPv6:
>
> - SYN retransmission (forward path blocked during setup)
> - SYN/ACK retransmission (reverse path blocked during setup)
> - Midstream RTO (forward path blocked on established connection)
> - Midstream ACK rehash (reverse path blocked on established connection)
> - PLB rehash (ECN-driven congestion on established connection)
> - Hash policy 1 negative test (rehash attempted but path unchanged)
> - No flowlabel leak (mp_hash does not alter on-wire flowlabel)
> - Dst rebuild consistency (route replace does not change path)
> - Dst rebuild consistency with syncookies (same via cookie_v6_check)
>
> The policy 1 test verifies that fib_multipath_hash_policy=1 computes
> a deterministic 5-tuple hash, so txhash re-rolls do not change the
> ECMP path while TcpTimeoutRehash still increments.
>
> The flowlabel leak test sets auto_flowlabels=0 and installs tc
> filters that drop TCP packets with nonzero flowlabel, confirming
> that fl6->mp_hash does not leak into the on-wire IPv6 flow label.
>
> The dst rebuild tests stream data, replace the ECMP route with
> identical nexthops (invalidating the cached dst), and verify that
> traffic stays on the same path. This confirms that the initial
> route lookup in tcp_v6_connect() and cookie_v6_check() uses the
> same hash as subsequent rebuilds via inet6_csk_route_socket().
> Set ECMP_REBUILD_ROUNDS=N for statistical confidence.
Hi Neil!
The test appears to be too flaky:
https://netdev.bots.linux.dev/contest.html?test=ecmp-rehash-sh
--
pw-bot: cr
prev parent reply other threads:[~2026-05-16 17:44 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-13 20:40 [PATCH net-next v5 0/2] tcp: rehash onto different local ECMP path on retransmit timeout Neil Spring
2026-05-13 20:40 ` [PATCH net-next v5 1/2] " Neil Spring
2026-05-13 20:40 ` [PATCH net-next v5 2/2] selftests: net: add local ECMP rehash test Neil Spring
2026-05-16 17:44 ` Jakub Kicinski [this message]
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=20260516104416.09aa5458@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuniyu@google.com \
--cc=linux-kselftest@vger.kernel.org \
--cc=ncardwell@google.com \
--cc=netdev@vger.kernel.org \
--cc=ntspring@meta.com \
--cc=pabeni@redhat.com \
--cc=shuah@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.