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
On Tue, Dec 3, 2013 at 5:41 AM, Adrian Chadd wrote:
>
> On 2 December 2013 03:45, Sepherosa Ziehau wrote:
> >
> > On Mon, Dec 2, 2013 at 1:02 PM, Adrian Chadd 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
On 2 December 2013 03:45, Sepherosa Ziehau wrote:
>
> On Mon, Dec 2, 2013 at 1:02 PM, Adrian Chadd 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 on, right? If it's migrated to
On Mon, Dec 2, 2013 at 1:02 PM, Adrian Chadd wrote:
> Hi! Thanks for the writeup!
>
> On 1 December 2013 20:17, Sepherosa Ziehau 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
>
>
On Mon, Dec 2, 2013 at 12:29 PM, Oleg Moskalenko wrote:
> 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 address,
> with conne
Hi! Thanks for the writeup!
On 1 December 2013 20:17, Sepherosa Ziehau 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 stays on the given
On Sat, Nov 30, 2013 at 2:42 AM, Ermal Luçi 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):
http://gitweb.dragonflybsd.org/
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 wrote:
> It would be nice to have this feature compiled and supported in FreeBSD
> kernel by default.
>
> Thanks
> Oleg
>
>
> On Fri, No
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 wrote:
> Also some discussions and improvements to it.
>
> http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2013-09/msg00165.html
>
>
> On Fri, No
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 wrote:
> Well seems Dragonfly has some version of it already from commit [1].
>
> In FreeBSD there is the framework for this with
On Fri, Nov 29, 2013 at 6:59 PM, Tim Kientzle wrote:
>
> On Nov 29, 2013, at 4:04 AM, 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 …
>
> These flags are used with TCP-based server
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 be
On Nov 29, 2013, at 4:04 AM, 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 …
These flags are used with TCP-based servers.
I’ve used them to make software upgrades go more smoothly.
Withou
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 interpr
On Fri, Nov 29, 2013 at 1: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!
>
> T
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 th
16 matches
Mail list logo
