Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour

On Mon, Dec 2, 2013 at 1:02 PM, Adrian Chadd <adrian_at_freebsd.org> wrote:

> Hi! Thanks for the writeup!
>
> On 1 December 2013 20:17, Sepherosa Ziehau <sepherosa_at_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 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 another CPU core then the
> listen queue still stays in the original hash group that's in a netisr
> on a different CPU?
>
>
As I wrote in the above brief introduction, Dfly currently relies on the
scheduler doing the proper thing (the scheduler does do a very good job
during my tests).  I need to export certain kind of socket option to make
that information available to user space programs.  Force UTHREAD binding
in kernel is not helpful, given in reverse proxy application, things are
different.  And even if that kind of binding information was exported to
user space, user space program still would have to poll it periodically (in
Dfly at least), since other programs binding to the same addr/port could
come and go, which will cause reorganizing of the inp localgroup in the
current Dfly implementation.

Best Regards,
sephe

-- 
Tomorrow Will Never Die