From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Dumazet Subject: Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode Date: Tue, 15 Dec 2015 09:10:24 -0800 Message-ID: <1450199424.8474.30.camel@edumazet-glaptop2.roam.corp.google.com> References: <877fnc7i0i.fsf@bytheb.org> <1443320655.3273.7.camel@edumazet-glaptop2.roam.corp.google.com> <1447222769.17135.92.camel@edumazet-glaptop2.roam.corp.google.com> <1447262610.17135.114.camel@edumazet-glaptop2.roam.corp.google.com> <1447267424.17135.115.camel@edumazet-glaptop2.roam.corp.google.com> <1447290541.22599.11.camel@edumazet-glaptop2.roam.corp.google.com> <20151215161456.GA3182@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: Tom Herbert , Tolga Ceylan , Aaron Conole , "David S. Miller" , Linux Kernel Network Developers To: Willy Tarreau Return-path: Received: from mail-pa0-f50.google.com ([209.85.220.50]:35655 "EHLO mail-pa0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932462AbbLORK0 (ORCPT ); Tue, 15 Dec 2015 12:10:26 -0500 Received: by mail-pa0-f50.google.com with SMTP id hk6so7760942pad.2 for ; Tue, 15 Dec 2015 09:10:26 -0800 (PST) In-Reply-To: <20151215161456.GA3182@1wt.eu> Sender: netdev-owner@vger.kernel.org List-ID: 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. Thanks.