[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20220131210208.69c671de@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date: Mon, 31 Jan 2022 21:02:08 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Akhmat Karakotov <hmukos@...dex-team.ru>
Cc: netdev@...r.kernel.org, davem@...emloft.net, edumazet@...gle.com,
eric.dumazet@...il.com, bpf@...r.kernel.org, ast@...nel.org,
daniel@...earbox.net, andrii@...nel.org, tom@...bertland.com,
zeil@...dex-team.ru, mitradir@...dex-team.ru
Subject: Re: [PATCH net-next v5 0/5] Make hash rethink configurable
On Mon, 31 Jan 2022 16:31:20 +0300 Akhmat Karakotov wrote:
> As it was shown in the report by Alexander Azimov, hash rethink at the
> client-side may lead to connection timeout toward stateful anycast
> services. Tom Herbert created a patchset to address this issue by applying
> hash rethink only after a negative routing event (3RTOs) [1]. This change
> also affects server-side behavior, which we found undesirable. This
> patchset changes defaults in a way to make them safe: hash rethink at the
> client-side is disabled and enabled at the server-side upon each RTO
> event or in case of duplicate acknowledgments.
>
> This patchset provides two options to change default behaviour. The hash
> rethink may be disabled at the server-side by the new sysctl option.
> Changes in the sysctl option don't affect default behavior at the
> client-side.
>
> Hash rethink can also be enabled/disabled with socket option or bpf
> syscalls which ovewrite both default and sysctl settings. This socket
> option is available on both client and server-side. This should provide
> mechanics to enable hash rethink inside administrative domain, such as DC,
> where hash rethink at the client-side can be desirable.
This appears to be 01b2a995156d ("Merge branch 'hash-rethink'") in
net-next, thanks!
Powered by blists - more mailing lists