Date: Thu, 19 Feb 2015 08:28:34 -0800 From: Adrian Chadd <adrian@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: "freebsd-arch@freebsd.org" <arch@freebsd.org> Subject: Re: RFC: bus_get_cpus(9) Message-ID: <CAJ-Vmom0ZEAqgoeJLhu2ORk6_z=-e4-pae8ArDAZJRbD7MgPzQ@mail.gmail.com> 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 19 February 2015 at 07:37, John Baldwin <jhb@freebsd.org> 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 wasn't suggesting we have RSS as a newbus method, just that drivers
don't necessarily need to call the bus method and iterate themselves.
I was suggesting that we do what i've done for rss, but as a generic
"how should devices create queues and map them to cpusets / interrupt
locality" and that calls the bus method(s) to discover topology and
query local-interrupt and local-memory sets to do things
appropriately.
Then RSS is just a flavour of that API call - network drivers could
either be RSS aware and call it to get the mapping, or call some
higher level bus API call to do the "generic" hints or whatever based
mapping.
-adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmom0ZEAqgoeJLhu2ORk6_z=-e4-pae8ArDAZJRbD7MgPzQ>