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: <alpine.DEB.2.00.1204241026410.735@wel-95.cs.helsinki.fi>
Date:	Tue, 24 Apr 2012 11:01:37 +0300 (EEST)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	Eric Dumazet <eric.dumazet@...il.com>
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, 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.


-- 
 i.
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ