netdev - Re: [PATCH net-next v2 1/2] tcp: derive delack_max with tcp_rto

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAPREpbb90pDeDOJF+jX=ULOG+b=abfXeemaFBt6woGJzCpp=Uw@mail.gmail.com>
Date: Mon, 3 Jun 2024 17:34:07 -0400
From: Kevin Yang <yyd@...gle.com>
To: David Laight <David.Laight@...lab.com>
Cc: David Miller <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, 
	Jakub Kicinski <kuba@...nel.org>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, 
	"ncardwell@...gle.com" <ncardwell@...gle.com>, "ycheng@...gle.com" <ycheng@...gle.com>, 
	"kerneljasonxing@...il.com" <kerneljasonxing@...il.com>, "pabeni@...hat.com" <pabeni@...hat.com>, 
	"tonylu@...ux.alibaba.com" <tonylu@...ux.alibaba.com>
Subject: Re: [PATCH net-next v2 1/2] tcp: derive delack_max with tcp_rto_min helper

thanks for the nice suggestions, sent v3
https://lore.kernel.org/netdev/20240603213054.3883725-1-yyd@google.com/

On Sat, Jun 1, 2024 at 10:56 AM David Laight <David.Laight@...lab.com> wrote:
>
> From: Kevin Yang
> > Sent: 30 May 2024 16:35
> > To: David Miller <davem@...emloft.net>; Eric Dumazet <edumazet@...gle.com>; Jakub Kicinski
> >
> > Rto_min now has multiple souces, ordered by preprecedence high to
> > low: ip route option rto_min, icsk->icsk_rto_min.
> >
> > When derive delack_max from rto_min, we should not only use ip
> > route option, but should use tcp_rto_min helper to get the correct
> > rto_min.
> ...
> > diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> > index f97e098f18a5..b44f639a9fa6 100644
> > --- a/net/ipv4/tcp_output.c
> > +++ b/net/ipv4/tcp_output.c
> > @@ -4163,16 +4163,9 @@ EXPORT_SYMBOL(tcp_connect);
> >
> >  u32 tcp_delack_max(const struct sock *sk)
> >  {
> > -     const struct dst_entry *dst = __sk_dst_get(sk);
> > -     u32 delack_max = inet_csk(sk)->icsk_delack_max;
> > -
> > -     if (dst && dst_metric_locked(dst, RTAX_RTO_MIN)) {
> > -             u32 rto_min = dst_metric_rtt(dst, RTAX_RTO_MIN);
> > -             u32 delack_from_rto_min = max_t(int, 1, rto_min - 1);
> > +     u32 delack_from_rto_min = max_t(int, 1, tcp_rto_min(sk) - 1);
>
> That max_t() is more horrid than most.
> Perhaps:
>                 = max(tcp_rto_min(sk), 2) - 1;
>
> >
> > -             delack_max = min_t(u32, delack_max, delack_from_rto_min);
> > -     }
> > -     return delack_max;
> > +     return min_t(u32, inet_csk(sk)->icsk_delack_max, delack_from_rto_min);
>
> Can that just be a min() ??
>
>         David
>
> >  }
> >
> >  /* Send out a delayed ack, the caller does the policy checking
> > --
> > 2.45.1.288.g0e0cd299f1-goog
> >
>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)