On Tue, Dec 15, 2015 at 09:10:24AM -0800, Eric Dumazet wrote: > On Tue, 2015-12-15 at 17:14 +0100, Willy Tarreau wrote: > > Hi Eric, > > > > On Wed, Nov 11, 2015 at 05:09:01PM -0800, Eric Dumazet wrote: > > > On Wed, 2015-11-11 at 10:43 -0800, Eric Dumazet wrote: > > > > On Wed, 2015-11-11 at 10:23 -0800, Tom Herbert wrote: > > > > > > > > > How about doing this in shutdown called for a listener? > > > > > > > > Seems a good idea, I will try it, thanks ! > > > > > > > > > > Arg, I forgot about this shutdown() discussion we had recently > > > with Oracle guys. > > > > > > It is currently used in linux to unblock potential threads in accept() > > > system call. > > > > > > This would prevent syn_recv sockets to be finally accepted. > > > > I had a conversation with an haproxy user who's concerned with the > > connection drops during the reload operation and we stumbled upon > > this thread. I was considering improving shutdown() as well for this > > as haproxy already performs a shutdown(RD) during a "pause" operation > > (ie: workaround for kernels missing SO_REUSEPORT). > > > > And I found that the code clearly doesn't make this possible since > > shutdown(RD) flushes the queue and stops the listening. > > > > However I found what I consider an elegant solution which works > > pretty well : by simply adding a test in compute_score(), we can > > ensure that a previous socket ranks lower than the current ones, > > and is never considered as long as the new ones are present. Here I > > achieved this using setsockopt(SO_LINGER). The old process just has > > to do this with a non-zero value on the socket it wants to put into > > lingering mode and that's all. > > > > I find this elegant since it keeps the same semantics as for a > > connected socket in that it avoids killing the queue, and that it > > doesn't change the behaviour for existing applications. It just > > turns out that listening sockets are set up without any lingering > > by default so we don't need to add any new socket options nor > > anything. > > > > Please let me know what you think about it (patch attached), if > > it's accepted it's trivial to adapt haproxy to this new behaviour. > > Well, problem is : some applications use LINGER on the listener, > you can not really hijack this flag.
Ah ? but what does it bring in this case ? I'm not seeing it used anywhere on a listening socket. The code took care of not breaking them though (ie they still accept if no other socket shows up with a higher score). Otherwise we'll have to switch to Tolga's patch, unless we find another socket option that can safely be combined and which makes sense (I often find it better not to make userland depend on new updates of includes when possible). Cheers, Willy -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
