Well seems Dragonfly has some version of it already from commit . In FreeBSD there is the framework for this with by defining PCBGROUP. Also the explanation of it at  and . It can achieve approximately the same features of SO_RESUSEPORT of linux. The only thing missing is the marketing behind it and i think and better RSS support. By looking at dates the support is there before linux so all you guys looking for it can experiment with it.
What i was trying to accomplish was something else from performance improvement and maybe put a sysctl behind it to make it more acceptable..  http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/740d1d9f7b7bf9c9c021abb8197718d7a2d441c9  http://fxr.watson.org/fxr/source/netinet/in_pcbgroup.c?im=bigexcerpts#L51  http://lists.freebsd.org/pipermail/svn-src-head/2011-June/028190.html On Fri, Nov 29, 2013 at 7:03 PM, Oleg Moskalenko <mom040...@gmail.com>wrote: > Tim, you are wrong. Read what is "multicast" definition, and read how UDP > and TCP sockets work in Linux 3.9+ kernels. > > Oleg . > > > On Fri, Nov 29, 2013 at 9:59 AM, 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 used with TCP-based servers. >> >> I’ve used them to make software upgrades go more smoothly. >> Without them, the following often happens: >> >> * Old server stops. In the process, all of its TCP connections are >> closed. >> >> * Connections to old server remain in the TCP connection table until the >> remote end can acknowledge. >> >> * New server starts. >> >> * New server tries to open port but fails because that port is “still in >> use” by connections in the TCP connection table. >> >> With these flags, the new server can open the port even though >> it is “still in use” by existing connections. >> >> >> > This is not the case today. >> > Only multicast sockets seem to have the behaviour of broadcasting the >> data >> > to all sockets sharing the same properties through these options! >> >> That is what multicast is for. >> >> If you want the same data sent to all listeners, then >> that is multicast behavior and you should be using >> a multicast socket. >> >> > The patch at  implements/corrects the behaviour for UDP sockets. >> >> You’re trying to turn all UDP sockets with those options >> into multicast sockets. >> >> If you want a multicast socket, you should ask for one. >> >> Tim >> >> _______________________________________________ >> freebsd-...@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" >> > > -- Ermal _______________________________________________ email@example.com mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"