Date: Thu, 19 Feb 2015 20:58:02 +0300 From: Slawa Olhovchenkov <slw@zxy.spb.ru> To: John Baldwin <jhb@freebsd.org> Cc: "freebsd-arch@freebsd.org" <arch@freebsd.org>, Adrian Chadd <adrian@freebsd.org> Subject: Re: RFC: bus_get_cpus(9) Message-ID: <20150219175802.GC46228@zxy.spb.ru> In-Reply-To: <6147240.5Rne9DUXyM@ralph.baldwin.cx> References: <1848011.eGOHhpCEMm@ralph.baldwin.cx> <CAJ-VmokFzuN2Q4ds6zV2M8rd%2B%2BbZ5M0oTaiFFBYueTekCL0s0w@mail.gmail.com> <6147240.5Rne9DUXyM@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Feb 19, 2015 at 10:37:28AM -0500, John Baldwin wrote:
> There's nothing preventing the RSS code from calling bus_get_cpus() internally
> to populate the info it returns in its APIs.
>
> That is, I imagine something like:
>
> #ifdef RSS
> queue_info = fetch_rss_info(dev);
> for (queue in queue_info) {
> create queue for CPU queue->cpu
> }
> #else
> /* Use bus_get_cpus directly and do 1:1 */
> #endif
>
> That is, I think RSS should provide a layer on top of new-bus, not be a
> bus_foo API. At some point all drivers might only have the #ifdef RSS case
> and not use bus_get_cpus() directly at all, but it doesn't seem like the RSS
> API is quite there yet.
I don't play with RSS (and RSS descrption wery complexity for me,
besides I think RSS API may be very simple (for listen socket case) --
just inform select/kevent/poll only pined to cpu handled interrupt),
but for RSS may be need use all cores -- and NUMA near and NUMA far,
for RSS-less case for interrupt best use only NUME near cores, leave
NUMA far cores for application (this separation in my case give aprox.
100% performance rise).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150219175802.GC46228>