netdev - Re: [PATCH v2 net] tcp: Enable header prediction for active open connections with MD5.

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] [thread-next>] [day] [month] [year] [list]

Date: Thu, 3 Aug 2023 17:02:27 +0200
From: Florian Westphal <fw@...len.de>
To: Eric Dumazet <edumazet@...gle.com>
Cc: Paolo Abeni <pabeni@...hat.com>, Florian Westphal <fw@...len.de>,
	Kuniyuki Iwashima <kuniyu@...zon.com>,
	"David S. Miller" <davem@...emloft.net>,
	Jakub Kicinski <kuba@...nel.org>, David Ahern <dsahern@...nel.org>,
	YOSHIFUJI Hideaki <yoshfuji@...ux-ipv6.org>,
	Kuniyuki Iwashima <kuni1840@...il.com>, netdev@...r.kernel.org
Subject: Re: [PATCH v2 net] tcp: Enable header prediction for active open
 connections with MD5.

Eric Dumazet <edumazet@...gle.com> wrote:
> On Thu, Aug 3, 2023 at 8:59 AM Paolo Abeni <pabeni@...hat.com> wrote:
> >
> > On Thu, 2023-08-03 at 08:44 +0200, Eric Dumazet wrote:
> > > I do not think we want to slow down fast path (no MD5), for 'header
> > > prediction' of MD5 flows,
> > > considering how slow MD5 is anyway (no GSO/GRO), and add yet another
> > > ugly #ifdef CONFIG_TCP_MD5SIG
> > > in already convoluted code base.
> >
> > Somewhat related, do you know how much header prediction makes a
> > difference for plain TCP? IIRC quite some time ago there was the idea
> > to remove header prediction completely to simplify the code overall -
> > then reverted because indeed caused regression in RR test-case. Do you
> > know if that is still true? would it make sense to re-evaluate that
> > thing (HP removal) again?
> >
> 
> I think Florian did this, he might recall the details.

Memory is hazy here, 31770e34e43d ("tcp: Revert "tcp: remove header prediction"")
has some clues.

One would need to refactor tcp_ack so that all the extra accesses are
only done if the packet matches expected next sequence without advancing
the window.  Not sure its worth doing, one would start to add tcp header
prediction v2, with little or no significant LOC savings.