<div dir="ltr"><div>Hi all,<br><br></div>Sorry for the top post.  Any follow-up on this?  Or I should just keep it as a local patch?<br><div><div><div class="gmail_extra"><br></div><div class="gmail_extra">Best Regards,<br>
sephe<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 2, 2013 at 1:16 PM, Sepherosa Ziehau <span dir="ltr"><<a href="mailto:sepherosa@gmail.com" target="_blank">sepherosa@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
Here is another round of SO_REUSEPORT support.  The plot is changed a<br>
little bit to allow smooth configure reloading and binary upgrading.<br>
Here is what happens when so_reuseport is enable (this does not affect<br>
single process model):<br>
- Master creates the listen sockets w/ SO_REUSEPORT, but does not configure them<br>
- The first worker process will inherit the listen sockets created by<br>
master and configure them<br>
- After master forked the first worker process all listen sockets are closed<br>
- The rest of the workers will create their own listen sockets w/ SO_REUSEPORT<br>
- During binary upgrade, listen sockets are no longer passed through<br>
environment variables, since new master will create its own listen<br>
sockets.  Well, the old master actually does not have any listen<br>
sockets opened :).<br>
<br>
The idea behind this plot is that at any given time, there is always<br>
one listen socket left, which could inherit the syncaches and pending<br>
sockets on the to-be-closed listen sockets.  The inheritance itself is<br>
handled by the kernel; I implemented this inheritance for DragonFlyBSD<br>
recently (<a href="http://gitweb.dragonflybsd.org/dragonfly.git/commit/02ad2f0b874fb0a45eb69750219f79f5e8982272" target="_blank">http://gitweb.dragonflybsd.org/dragonfly.git/commit/02ad2f0b874fb0a45eb69750219f79f5e8982272</a>).<br>

 I am not tracking Linux's code, but I think Linux side will<br>
eventually get (or already got) the proper fix.<br>
<br>
The patch itself:<br>
<a href="http://leaf.dragonflybsd.org/~sephe/ngx_soreuseport3.diff" target="_blank">http://leaf.dragonflybsd.org/~sephe/ngx_soreuseport3.diff</a><br>
<br>
Configuration reloading and binary upgrading will not be interfered as<br>
w/ the first 2 patches.<br>
<br>
Binary upgrading reverting method 1 ("Send the HUP signal to the old<br>
master process. ...") will not be interfered as w/ the first 2<br>
patches.  There still could be some glitch (but not that worse as w/<br>
the first 2 patches) if binary upgrading reverting method 2 ("Send the<br>
TERM signal to the new master process. ...") is used.  I think we<br>
probably just need to mention that in the document.<br>
<br>
Best Regards,<br>
sephe<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Tomorrow Will Never Die<br>
</font></span></blockquote></div><br><br clear="all"><br>-- <br>Tomorrow Will Never Die
</div></div></div></div>