svn commit: r282280 - in head/sys/dev: e1000 ixgbe ixl

[Gleb Smirnoff]

On Fri, May 01, 2015 at 10:47:43AM -0400, John Baldwin wrote:
J> > J> > While you are here, let me remind you about this plan:
J> > J> > 
J> > J> > https://lists.freebsd.org/pipermail/svn-src-head/2014-October/063575.html
J> > J> > 
J> > J> > We can prototype the API to userland now, write down a utility that uses
J> > J> > it, or add the functionality to an existing utility. And start with Intel
J> > J> > drivers, that seem to be most interested in extra stats.
J> > J> 
J> > J> So the importaing thing here is that if_get_counter() is still doing
J> > J> per-ifnet stats.  The stat you underlined above is per-queue instead.
J> > J> We well need more explicitly knowledge of queues outside of drivers
J> > J> and in the stack itself to support a generic framework for per-queue
J> > J> stats.
J> > 
J> > This depends on how generic we want the API to be. Of course, we can add
J> > an extra argument to if_get_counter().
J> > 
J> > However, if we don't expect the number of queues to exceed a reasonable
J> > number of 255 :), we can fit the functionality into existing API.
J> > We can keep the queue number in the highest 8 bits of the ift_counter
J> > parameter.
J> > 
J> > #define	IFCOUNTER_MASK		0x00ffffff
J> > #define	IFCOUNTER_QUEUE(c)	((c) >> 24)
J> 
J> I'd prefer that expose queues more directly and figure out how to handle
J> per-queue stats then (e.g. do we have some sort of driver-independent
J> structure that each ifnet has 1 or more of that maps to a queue and has
J> driver provided methods, etc.  If so you could have a driver method for
J> queue stats).  Note that I did use if_get_counter to report the
J> per-interface stats instead of adding a new sysctl.

What do you prefer: an extra argument to the if_get_counter() or a extra
ifop?

-- 
Totus tuus, Glebius.