Date: Tue, 5 May 2015 12:59:06 +0300 From: Gleb Smirnoff <glebius@FreeBSD.org> To: John Baldwin <jhb@freebsd.org> 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> In-Reply-To: <1850166.lcXaWhCA6D@ralph.baldwin.cx> References: <201504301823.t3UINd74073186@svn.freebsd.org> <2463555.FfYUgqxYi8@ralph.baldwin.cx> <20150505064556.GM34544@FreeBSD.org> <1850166.lcXaWhCA6D@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150505095906.GO34544>