netdev - Re: Loopback performance from kernel 2.6.12 to 2.6.37

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

Message-Id: <20101118.094837.260089185.davem@davemloft.net>
Date:	Thu, 18 Nov 2010 09:48:37 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	eric.dumazet@...il.com
Cc:	jdb@...x.dk, netdev@...r.kernel.org, lawrence@...kmo.org
Subject: Re: Loopback performance from kernel 2.6.12 to 2.6.37

From: Eric Dumazet <eric.dumazet@...il.com>
Date: Thu, 18 Nov 2010 18:41:53 +0100

> Le jeudi 18 novembre 2010 à 14:52 +0100, Eric Dumazet a écrit :
>> Le mardi 09 novembre 2010 à 15:25 +0100, Eric Dumazet a écrit :
>> 
>> My tests show a problem with backlog processing, and too big TCP
>> windows. (at least on loopback and wild senders)
>> 
>> Basically, with huge tcp windows we have now (default 4 Mbytes),
>> the reader process can have to process up to 4Mbytes of backlogged data
>> in __release_sock() before returning from its 'small' read(fd, buffer,
>> 1024) done by netcat.
>> 
>> While it processes this backlog, it sends tcp ACKS, allowing sender to
>> send new frames that might be dropped because of sk_rcvqueues_full(), or
>> continue to fill receive queue up to the receiver window, feeding the
>> task in __release_sock() [loop]
>> 
>> 
>> This blows cpu caches completely [data is queued, and the dequeue is
>> done long after], and latency of a single read() can be very high. This
>> blocks the pipeline of user processing eventually.

Thanks for looking into this Eric.

We definitely need some kind of choke point so that TCP never
significantly exceeds the congestion window point at which throughput
stops increasing (and only latency does).

One idea is that when we integrate Lawrence Brakmo's TCP-NV congestion
control algorithm, we can try enabling it by default over loopback.

Loopback is kind of an interesting case of the problem scenerio
Lawrence is trying to solve.

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