listening sockets as non sockets

[Julien Charbon]

 Hi Gleb,

On 1/27/17 1:52 AM, Gleb Smirnoff wrote:
>   as some of you already heard, I'm trying to separate listening sockets
> into a new file descriptor type. If we look into current struct socket,
> we see that some functional fields belong to normal data flow sockets,
> and other belong to listening socket. They are never used simultaneously.
> Now, if we look at socket API, we see that once a socket underwent transformation
> to a listening socket, only 3 regular syscalls now may be called: listen(2),
> accept(2) and close(2) and a subset of ioctl() and setsockopt() parameters is
> accepted. A listening socket cannot be closed from the protocol side, only from
> user side. So, listening socket is so different from a dataflow socket, that
> separating them looks architecturally right thing to do.
> 
> The benefits are:
> 
> 1) Nicer code (I hope).
> 2) Smaller 'struct socket'.
> 3) Having two different locks for socket and solisten, we can try to get rid
>    of ACCEPT_LOCK global lock.
> 
> The patch is in a very pre-alpha state. It has been run only in my bhyve VM.
> 
> It passes regression tests from tools/regression/sockets and tests/sys,
> including the race tests, and including accept filter ones.
> 
> For TCP it passes basic functionality testing, but likely there are still races
> remaining after ACCEPT_LOCK removal.
> <snip>
> I've put current snapshot to Phab, so that you can view it there. The snap
> patch is also attached to this email.
> 
> https://reviews.freebsd.org/D9356
> 
> At this moment I'd like to start doing some testing (and doing polishing
> in parallel), and here I seek for your help. Those, who run FreeBSD at
> very high connection rates and observe contention on the accept global
> mutex, anybody willing to collaborate with me on this?

 Good idea, we are (obviously) interested by point #3 (Get rid of ACCEPT
global lock) and its connection rate scalability improvement.

 I might be able to look at potential race conditions related to
ACCEPT_LOCK and SO_ACCEPTFILTER usage (even if I am more used to
INP_INFO lock), but I can certainly provide performance numbers and lock
contention metrics using our setup.

 Do you think it is the right time to start performance testing with
your change?  Or it is a bit premature?

--
Julien

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-net/attachments/20170127/a693e104/attachment.sig>