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
signature.asc
Description: OpenPGP digital signature
