Date: Mon, 2 Dec 2013 19:45:54 +0800 From: Sepherosa Ziehau <sepherosa@gmail.com> To: Adrian Chadd <adrian@freebsd.org> Cc: =?ISO-8859-1?Q?Ermal_Lu=E7i?= <eri@freebsd.org>, freebsd-net <freebsd-net@freebsd.org>, Oleg Moskalenko <mom040267@gmail.com>, Tim Kientzle <kientzle@freebsd.org>, "freebsd-current@freebsd.org" <freebsd-current@freebsd.org> Subject: Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour Message-ID: <CAMOc5cyM-%2Bvau7BsZQ5F5L95EQgN=pJqru=9aK_0aJ%2BVUk=gxQ@mail.gmail.com> In-Reply-To: <CAJ-Vmonc7SVxndmVN1jphFRa5svD5BdnMrCudSbYkx4djHXW0A@mail.gmail.com> References: <CAPBZQG29BEJJ8BK=gn%2Bg_n5o7JSnPbsKQ-=3=6AkFOxzt%2B=wGQ@mail.gmail.com> <4053E074-EDC5-49AB-91A7-E50ABE36602E@freebsd.org> <CALDtMrKvwXW-ou8X7zsKx2ST=dKD7FqHvvnQtGo30znTWU%2BVQQ@mail.gmail.com> <CAPBZQG0=bcHyv7aZse=WKfjk5=6D2-%2B6EQHiAaDZqGtaodhMMA@mail.gmail.com> <CAMOc5cwFGwk0dS5VT-YxfP3Yt38R8aO-KJTX6W832uOFEdavgA@mail.gmail.com> <CAJ-Vmonc7SVxndmVN1jphFRa5svD5BdnMrCudSbYkx4djHXW0A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Dec 2, 2013 at 1:02 PM, Adrian Chadd <adrian@freebsd.org> wrote: > Hi! Thanks for the writeup! > > On 1 December 2013 20:17, Sepherosa Ziehau <sepherosa@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAMOc5cyM-%2Bvau7BsZQ5F5L95EQgN=pJqru=9aK_0aJ%2BVUk=gxQ>