From owner-freebsd-arch@FreeBSD.ORG Thu Feb 19 17:03:35 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6AFD2DA0; Thu, 19 Feb 2015 17:03:35 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 42450C5; Thu, 19 Feb 2015 17:03:35 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D13C7B91F; Thu, 19 Feb 2015 12:03:33 -0500 (EST) From: John Baldwin To: Adrian Chadd Subject: Re: RFC: bus_get_cpus(9) Date: Thu, 19 Feb 2015 12:03:01 -0500 Message-ID: <2650364.MV3AvSBuVe@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: References: <1848011.eGOHhpCEMm@ralph.baldwin.cx> <6147240.5Rne9DUXyM@ralph.baldwin.cx> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 19 Feb 2015 12:03:33 -0500 (EST) Cc: "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 17:03:35 -0000 On Thursday, February 19, 2015 08:28:34 AM Adrian Chadd wrote: > On 19 February 2015 at 07:37, 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 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. Can you provide a sample API (function prototype, etc.)? Aside from RSS (which will have its own API for other reasons), I don't know of another use case that is well understood enough to let us build an abstraction on yet (we all know the perils of abstracting from one use case), so I'm hesitant to go much further than "these are the best place to do interrupts". -- John Baldwin