From owner-svn-src-all@FreeBSD.ORG Tue May 5 09:59:17 2015 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D60D95D2; Tue, 5 May 2015 09:59:16 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebius.int.ru", Issuer "cell.glebius.int.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 740851909; Tue, 5 May 2015 09:59:15 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.9/8.14.9) with ESMTP id t459x6iF048389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 5 May 2015 12:59:06 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id t459x6FE048388; Tue, 5 May 2015 12:59:06 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 5 May 2015 12:59:06 +0300 From: Gleb Smirnoff To: John Baldwin Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r282280 - in head/sys/dev: e1000 ixgbe ixl Message-ID: <20150505095906.GO34544@FreeBSD.org> References: <201504301823.t3UINd74073186@svn.freebsd.org> <2463555.FfYUgqxYi8@ralph.baldwin.cx> <20150505064556.GM34544@FreeBSD.org> <1850166.lcXaWhCA6D@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1850166.lcXaWhCA6D@ralph.baldwin.cx> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 09:59:17 -0000 On Tue, May 05, 2015 at 05:32:11AM -0400, John Baldwin wrote: J> > On Mon, May 04, 2015 at 04:01:28PM -0400, John Baldwin wrote: J> > J> > Your answer seems quite orthogonal to my question. I reread it couple of times, J> > J> > but still can't figure out how exactly do you prefet to fetch per-queue stats. J> > J> > Can you please explain in more detail? J> > J> J> > J> struct if_queue { J> > J> struct ifnet *ifq_parent; J> > J> void (*ifq_get_counter)(struct if_queue *, ift_counter); J> > J> ... J> > J> }; J> > J> J> > J> (Pretend that if_queue is a new object type and that each RX or TX queue on a J> > J> NIC has one.) J> > J> > This looks like a driver with 1024 queues would carry extra 1024 function pointers J> > per ifnet. Is it really worth? Could it be that queue #0 differs from queue #1? J> > Even, if a rare case when queue #N differs from queue #M do exist, they still J> > can share the pointer and the differentiating logic would be in the function J> > itself. J> J> Drivers with 1024 queues already have several pointers, however, you could J> have a "class" pointer (something ifnet doesn't have) like 'cdevsw' where you J> have a single structure containing the ops and the various queues have a pointer J> to that instead of having N duplicated function pointers. OTOH, you could probably J> keep this as an ifnet op, but accept a queue pointer as the argument still (that J> would give a similar effect). J> J> If you really want to trim function pointers though, fix ifnet to not duplicate J> them and use a shared ifnetsw among instances. :) Note that my own paragraph quoted below states that this is exactly what I did in projects/ifnet. J> > Right now, in the projects/ifnet branch, I'm developing in quite opposite J> > direction - many instances of the same driver share the set of interface J> > options. This is done to shrink struct ifnet. J> > J> > What's wrong with KPI when the queue number is parameter to an ifop? This J> > KPI would also hide the queue pointers from the stack, which are quite J> > driver specific. J> J> I think at some point we will want stack awareness in the stack for more than J> just stats. For example, the whole buf_ring/if_transmit thing has been non-ideal J> in terms of requiring drivers to duplicate a lot of code that was previously J> hidden from them making the drivers more complex (and fragile). Several of us J> would like to push the knowledge of the software ring (which is per-TX queue) J> back up out of drivers, but that will require some per-queue state stored outside J> of drivers. You could certainly do that with parallel arrays instead, but I'm J> not sure that is better than having a structure (at least I'm not sure that is J> as easy to reason about when you are working on the stack) Well, if the drivers access the structure functionally: dequeue, putback, etc., then this isn't a big deal. When the structure is ready, and we got drivers capable of working with it, we can introduce if_transmit_queue. I hope by that time projects/ifnet will be finalized, and expanding functionality of ifnet will be much easier. -- Totus tuus, Glebius.