From owner-freebsd-arch@FreeBSD.ORG  Thu Feb 19 17:58:05 2015
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
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 5666E4D6;
 Thu, 19 Feb 2015 17:58:05 +0000 (UTC)
Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client did not present a certificate)
 by mx1.freebsd.org (Postfix) with ESMTPS id 0BEFF960;
 Thu, 19 Feb 2015 17:58:05 +0000 (UTC)
Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD))
 (envelope-from <slw@zxy.spb.ru>)
 id 1YOVMQ-000Jfd-Gl; Thu, 19 Feb 2015 20:58:02 +0300
Date: Thu, 19 Feb 2015 20:58:02 +0300
From: Slawa Olhovchenkov <slw@zxy.spb.ru>
To: John Baldwin <jhb@freebsd.org>
Subject: Re: RFC: bus_get_cpus(9)
Message-ID: <20150219175802.GC46228@zxy.spb.ru>
References: <1848011.eGOHhpCEMm@ralph.baldwin.cx>
 <CAJ-VmokFzuN2Q4ds6zV2M8rd++bZ5M0oTaiFFBYueTekCL0s0w@mail.gmail.com>
 <6147240.5Rne9DUXyM@ralph.baldwin.cx>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <6147240.5Rne9DUXyM@ralph.baldwin.cx>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: slw@zxy.spb.ru
X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false
Cc: "freebsd-arch@freebsd.org" <arch@freebsd.org>,
 Adrian Chadd <adrian@freebsd.org>
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.18-1
Precedence: list
List-Id: Discussion related to FreeBSD architecture <freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arch>,
 <mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch/>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
 <mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Feb 2015 17:58:05 -0000

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).