netdev - Re: [PATCH 2/2 net-next] tcp: sk_add_backlog() is too agressive for TCP

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]

Message-ID: <1335257370.5205.129.camel@edumazet-glaptop>
Date:	Tue, 24 Apr 2012 10:49:30 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Ilpo Järvinen <ilpo.jarvinen@...sinki.fi>
Cc:	David Miller <davem@...emloft.net>, rick.jones2@...com,
	Netdev <netdev@...r.kernel.org>, therbert@...gle.com,
	ncardwell@...gle.com, maze@...gle.com,
	Yuchung Cheng <ycheng@...gle.com>
Subject: Re: [PATCH 2/2 net-next] tcp: sk_add_backlog() is too agressive
 for TCP

On Tue, 2012-04-24 at 11:01 +0300, Ilpo Järvinen wrote:
> On Tue, 24 Apr 2012, Eric Dumazet wrote:
> 
> > On Mon, 2012-04-23 at 22:37 +0200, Eric Dumazet wrote:
> > 
> > > We could try to coalesce ACKs before backlogging them. I'll work on
> > > this.
> > 
> > I did an experiment, and found a basic coalescing was not working in
> > case of packet loss and SACK storm.
> 
> ...That case might also have some performance issues at the receiver end 
> when a hole is filled and TCP pushes stuff higher up.
> 
> > Doing a smart coalescing in this case sounds really complex.
> 
> Why's that? ...We'd compare options 32-bit at a time (like you already do 
> anyway) and if we find difference we check the previous bits to validate 
> it's a SACK option (the changing one should be in the first start-end 
> pair). ...As long as there's no hole in every other segment we'd be 
> winners I think.
> 
> > Should we really continue this way ? 
> 
> Why not, but wouldn't it be nicer to coalesce them already in GRO below 
> with an assumption that GRO is likely to find some "mss" equivivalent 
> which tells the gap between consecutive ACK (or even SACK) seqnos?
> 
> I've been long thinking that it would be nice to run offloading for ACKs 
> too, and possibly even for SACKs, in both ends, although that might not be 
> possible with other than GSO/GRO, at least atm.
> 
> 


GRO doesnt coalesce pure acks, thats part of GRO contract.

By the way, I find GRO less and less attractive, if we have fragged skbs
provided by drivers, we can do the GRO almost for free in tcp stack,
instead of very complex/duplicated logic before tcp stack.

http://git.kernel.org/?p=linux/kernel/git/davem/net-next.git;a=commit;h=1402d366019fedaa2b024f2bac06b7cc9a8782e1

Doing this coalescing in tcp stack solves many problems GRO is unable to
address, like reordering...



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html