[brussels-dev] kstats and brussels

[Garrett D'Amore]

Sowmini asked me to write a brief proposal about kstats and brussels; 
here it is.

Problem Statement
----------------

There are three problems with kstats within Nemo that I hope Brussels 
will solve.

The first problem with Nemo currently is that only a fixed set of kstats 
are supported, and adding new kstats is a PITA.  I've filed two PSARC 
cases for this recently (2007/220 and 2007/296), and one putback.  
Another putback is pending. 

The alternative is for drivers to do _both_ kstats on their own, and 
support Nemo mac_stat() entry points.  Entirely inelegant.  (Btw, the 
old GLDv2 suffered this flaw.)  This also means that mac_stat

The second problem is simply API growth.  One can view stats as natural 
properties.  Many drivers even explicitly export ndd tunables in their 
own kstat.  Having a separate kind of API for drivers to have to 
implement kstats _in addition_ to the API they will already be doing for 
Brussels seems wasteful.  Brussels should reduce, not increase, code 
sizes in device drivers.

The third problem is that kstat collection under Nemo is expensive for 
drivers that need to do non-trivial effort to collect statistics.  By 
that, I mean that if you have to reclaim buffers, or do some other 
expensive operation, to get accurate statistics, then you want to do it 
_once_ for a given kstat snapshot.  With Nemo, you don't get to know 
about the start/end of snapshots, so instead of having one expensive 
operation amortized across all the stats, you have one expensive 
operation _per_ statistic.  Not a pretty way to do this.


Solution
-------

Kstats are really just another form of (read-only) property.  Therefore, 
I'd like Brussels to implement the kstats on behalf of the driver, doing 
the getprop()/setprop() as needed on the behalf of the driver, and 
exporting the results as a kstat.  This would replace the current 
mac_stat() functionality.

The second thing, is that we need drivers to know when to collect, save, 
and destroy snapshot data, so they do it once per system-wide snapshot, 
instead of once per stat.  To this end, what I'd like to see is some new 
API that Brussels provides to mark the "start" and "end" of statistic 
collection.  This could be done with a special reserved property, or it 
could be done with a new set of entry points.  This solves the kstat 
collection performance problem within Nemo.