netdev - RE: [PATCH 0/5]: soreuseport: Bind multiple sockets to the same port

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:	Tue, 15 Jan 2013 09:34:30 -0000
From:	"David Laight" <David.Laight@...LAB.COM>
To:	"Tom Herbert" <therbert@...gle.com>, <netdev@...r.kernel.org>,
	<davem@...emloft.net>
Cc:	<netdev@...kandruth.co.uk>, <eric.dumazet@...il.com>
Subject: RE: [PATCH 0/5]: soreuseport: Bind multiple sockets to the same port

> -----Original Message-----
> From: netdev-owner@...r.kernel.org [mailto:netdev-owner@...r.kernel.org] On Behalf Of Tom Herbert
> Sent: 14 January 2013 20:00
> To: netdev@...r.kernel.org; davem@...emloft.net
> Cc: netdev@...kandruth.co.uk; eric.dumazet@...il.com
> Subject: [PATCH 0/5]: soreuseport: Bind multiple sockets to the same port
> 
> Rebasing the soreuseport patches to 3.8.  No material changes since
> first posted.
> ---
> These patches implements so_reuseport (SO_REUSEPORT socket option) for
> TCP and UDP.  For TCP, so_reuseport allows multiple listener sockets
> to be bound to the same port.
>....
> 
> The motivating case for so_resuseport in TCP would be something like
> a web server binding to port 80 running with multiple threads, ...
> 2) accept on a single
> listener socket from multiple threads
> In case #2, the proportion of connections accepted per thread tends
> to be uneven under high connection load (assuming simple event loop:
> while (1) { accept(); process() }, wakeup does not promote fairness
> among the sockets.  We have seen the  disproportion to be as high
> as 3:1 ratio between thread accepting most connections and the one
> accepting the fewest.  With so_reusport the distribution is
> uniform.

Hmmm.... do you need that sort of fairness between the threads?

If one request takes longer than average to process, then you
don't want other requests to be delayed when there are other
idle worker processes.

Also having the same thread normally collect a request would
make it more likely that the required code/data be in the
cache of the cpu (assuming that the main reason for multiple
threads is to load balance over multiple cpus, and with the
threads tied to a single cpu).

If there are a lot of processes sleeping in accept() (on the same
socket) it might be worth looking at which is actually woken
when a new connection arrives. If they are sleeping in poll/select
it is probably more difficult (but not impossible) to avoid waking
all the processes for every incoming connection.

	David

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