netdev - Re: [PATCH 1/1] TCP: increase default initial receive window.

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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 21 Dec 2010 19:49:07 +0100
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	John Heffner <johnwheffner@...il.com>
Cc:	Nandita Dukkipati <nanditad@...gle.com>,
	"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
	Tom Herbert <therbert@...gle.com>,
	Laurent Chavey <chavey@...gle.com>,
	Yuchung Cheng <ycheng@...gle.com>
Subject: Re: [PATCH 1/1] TCP: increase default initial receive window.

Le mardi 21 décembre 2010 à 13:27 -0500, John Heffner a écrit :
> I know this has already been applied, but one thing to think about:
> Linux announces a small initial window to prevent overflowing the
> receive buffer when receiving segments smaller than the link MTU.

Overflowing receive buffer ? Which one ? Do you mean NIC RX ring
buffer ?

> Increasing this even to 10 segments might have some negative
> consequences.  I recall, for instance, some drivers when configured
> with a 9000 byte MTU, have a single pool of receive buffers all 16k
> (the next highest power of 2).  So each received segment will get 16k
> of allocated memory accounted to it, even if the incoming segments are
> <=1460 bytes long.  The default initial rcvbuf of 87380 bytes is less
> than the 160k of memory that the initial window might consume, so
> we're going to start hitting the very slow path of coalescing segments
> to get back under memory bounds.

Patch is not allowing 87380 bytes, but 10 segments, limited to 14600
bytes. Its very conservative IMHO.

> 
> Some drivers are smarter about having multiple pools of receive
> buffers with different sizes, so it might not be so easy to hit this
> condition.  I haven't looked at any of them for a while.  Is this
> still a real concern?

I dont think so. You would have problem anyway, since the patch changes
only _initial_ receive window. After some kbytes of data exchanged,
window is probably larger.


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