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]

Message-ID: <AE90C24D6B3A694183C094C60CF0A2F6026B7112@saturn3.aculab.com>
Date:	Thu, 17 Jan 2013 09:53:12 -0000
From:	"David Laight" <David.Laight@...LAB.COM>
To:	"Tom Herbert" <therbert@...gle.com>
Cc:	<netdev@...r.kernel.org>, <davem@...emloft.net>,
	<netdev@...kandruth.co.uk>, <eric.dumazet@...il.com>
Subject: RE: [PATCH 0/5]: soreuseport: Bind multiple sockets to the same port

> We had considered solving this within accept.  The problem is that
> there's no way to indicate how much work a thread should do via
> accept.  For instance, an event loop usually would look like:
> 
> while (1) {
>     fd = accept();
>     process(fd);
> }
> 
> With multiple threads, the number of accepted sockets in a particular
> thread is non-deterministic...

If your loop looks like that then each thread is only processing
a single socket and won't call accept() again until it is idle.

OTOH if each thread is processing multiple requests using
poll/select (or similar) at the top of the loop then a single
thread is likely to pick up a large number of connections.

Given that both poll and select are inefficient with very large
numbers of fds (every call is usually o(n) [1]), the kernel will
support some kind of event mechanism, maybe tweaking that to
signal the waiters in turn would also work - and be more general.

It might also be possible to do something on the user side of
sockets to generate additional fd with their own queue?
(IMHO some of the SCTP stuff should have been done that way).

	David

[1] I've known systems where it was actually o(n*n) because
the relevant kernel used a linked list to map fd to kernel
file structures! By the time you got to 1000 fd this dominated.

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