[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANn89i+k-EP+Xc8WWsESDGk+6dC31Tp0gSXg7MMdsB+sXmsm-g@mail.gmail.com>
Date: Mon, 10 Feb 2025 09:18:10 +0100
From: Eric Dumazet <edumazet@...gle.com>
To: Jason Xing <kerneljasonxing@...il.com>
Cc: "David S . Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org,
Neal Cardwell <ncardwell@...gle.com>, Kuniyuki Iwashima <kuniyu@...zon.com>,
Jason Xing <kernelxing@...cent.com>, Simon Horman <horms@...nel.org>, eric.dumazet@...il.com
Subject: Re: [PATCH net-next 4/5] tcp: add the ability to control max RTO
On Sat, Feb 8, 2025 at 6:37 AM Jason Xing <kerneljasonxing@...il.com> wrote:
>
> On Fri, Feb 7, 2025 at 11:31 PM Eric Dumazet <edumazet@...gle.com> wrote:
> >
> > Currently, TCP stack uses a constant (120 seconds)
> > to limit the RTO value exponential growth.
> >
> > Some applications want to set a lower value.
> >
> > Add TCP_RTO_MAX_MS socket option to set a value (in ms)
> > between 1 and 120 seconds.
> >
> > It is discouraged to change the socket rto max on a live
> > socket, as it might lead to unexpected disconnects.
> >
> > Following patch is adding a netns sysctl to control the
> > default value at socket creation time.
>
> I assume a bpf extension could be considered as a follow up patch on
> top of the series?
I left BPF and MPTP follow ups being handled by their owners
Powered by blists - more mailing lists