Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour

2013-12-05 Thread Sepherosa Ziehau
On Tue, Dec 3, 2013 at 5:41 AM, Adrian Chadd adr...@freebsd.org wrote: On 2 December 2013 03:45, Sepherosa Ziehau sepher...@gmail.com wrote: On Mon, Dec 2, 2013 at 1:02 PM, Adrian Chadd adr...@freebsd.org wrote: Ok, so given this, how do you guarantee the UTHREAD stays on the given

Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour

2013-12-05 Thread Adrian Chadd
I was thinking of n netisrs per m CPUs, where n m; or maybe 1 netisr for m CPUs, where m is less than the total number. Having 48 cores contending on netisr stuff is a bit crazy. It's highly unlikely you need that many cores doing packet pushing. -a

Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour

2013-12-02 Thread Sepherosa Ziehau
On Mon, Dec 2, 2013 at 12:29 PM, Oleg Moskalenko mom040...@gmail.comwrote: Sepherosa, while reading your description I noticed another long-standing problem for UDP application developers: the UDP sockets are always hashed with 2-tuple. But UDP sockets can be connected, too, to a remote

Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour

2013-12-02 Thread Sepherosa Ziehau
On Mon, Dec 2, 2013 at 1:02 PM, Adrian Chadd adr...@freebsd.org wrote: Hi! Thanks for the writeup! On 1 December 2013 20:17, Sepherosa Ziehau sepher...@gmail.com wrote: I also put up a brief description of SO_REUSEPORT in dfly; may be useful to you:

Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour

2013-12-02 Thread Adrian Chadd
On 2 December 2013 03:45, Sepherosa Ziehau sepher...@gmail.com wrote: On Mon, Dec 2, 2013 at 1:02 PM, Adrian Chadd adr...@freebsd.org wrote: Ok, so given this, how do you guarantee the UTHREAD stays on the given CPU? You assume it stays on the CPU that the initial listen socket was created

Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour

2013-12-01 Thread Sepherosa Ziehau
On Sat, Nov 30, 2013 at 2:42 AM, Ermal Luçi e...@freebsd.org wrote: Well seems Dragonfly has some version of it already from commit [1]. The distribution algorithm was changed a little bit after initial commit to gain more idle time (bnx(4) output has already been maxed out):

Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour

2013-12-01 Thread Adrian Chadd
Hi! Thanks for the writeup! On 1 December 2013 20:17, Sepherosa Ziehau sepher...@gmail.com wrote: I also put up a brief description of SO_REUSEPORT in dfly; may be useful to you: http://leaf.dragonflybsd.org/~sephe/netisr_so_reuseport.txt Ok, so given this, how do you guarantee the UTHREAD

[PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour

2013-11-29 Thread Ermal Luçi
Hello, since SO_REUSEADDR and SO_REUSEPORT are supposed to allow two daemons to share the same port and possibly listening ip, you would expect if you bind two daemon with such options to same port to see the same traffic on both! This is not the case today. Only multicast sockets seem to have

Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour

2013-11-29 Thread Daniel Nebdal
On Fri, Nov 29, 2013 at 1:04 PM, Ermal Luçi e...@freebsd.org wrote: Hello, since SO_REUSEADDR and SO_REUSEPORT are supposed to allow two daemons to share the same port and possibly listening ip, you would expect if you bind two daemon with such options to same port to see the same traffic on

Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour

2013-11-29 Thread Julian Elischer
On 11/29/13, 8:04 PM, Ermal Luçi wrote: Hello, since SO_REUSEADDR and SO_REUSEPORT are supposed to allow two daemons to share the same port and possibly listening ip, you would expect if you bind two daemon with such options to same port to see the same traffic on both! this is not how I

Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour

2013-11-29 Thread Tim Kientzle
On Nov 29, 2013, at 4:04 AM, Ermal Luçi e...@freebsd.org wrote: Hello, since SO_REUSEADDR and SO_REUSEPORT are supposed to allow two daemons to share the same port and possibly listening ip … These flags are used with TCP-based servers. I’ve used them to make software upgrades go more

Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour

2013-11-29 Thread Ermal Luçi
Well seems Dragonfly has some version of it already from commit [1]. In FreeBSD there is the framework for this with by defining PCBGROUP. Also the explanation of it at [2] and [3]. It can achieve approximately the same features of SO_RESUSEPORT of linux. The only thing missing is the marketing

Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour

2013-11-29 Thread Ermal Luçi
On Fri, Nov 29, 2013 at 6:59 PM, Tim Kientzle kient...@freebsd.org wrote: On Nov 29, 2013, at 4:04 AM, Ermal Luçi e...@freebsd.org wrote: Hello, since SO_REUSEADDR and SO_REUSEPORT are supposed to allow two daemons to share the same port and possibly listening ip … These flags are

Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour

2013-11-29 Thread Ermal Luçi
Also some discussions and improvements to it. http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2013-09/msg00165.html On Fri, Nov 29, 2013 at 7:42 PM, Ermal Luçi e...@freebsd.org wrote: Well seems Dragonfly has some version of it already from commit [1]. In FreeBSD there is the framework

Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour

2013-11-29 Thread Ermal Luçi
And some better marketing from Dragonfly about it http://forum.nginx.org/read.php?29,241283,241283 :) On Fri, Nov 29, 2013 at 7:55 PM, Ermal Luçi e...@freebsd.org wrote: Also some discussions and improvements to it. http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2013-09/msg00165.html

Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour

2013-11-29 Thread Adrian Chadd
Sure, is there a TCP version of this patch floating around? How's it doing load balancing to multiple listeners? -a On 29 November 2013 11:28, Oleg Moskalenko mom040...@gmail.com wrote: It would be nice to have this feature compiled and supported in FreeBSD kernel by default. Thanks Oleg