tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Using event counters with network interfaces, is there a reason they're all ifdefed out of mainline use?



        Hello.  I notice that most, if not all, of the network drivers in
NetBSD have interface counters which they use to track things like
collisions, CRC errors, framing errors, etc.  It looks like these counters,
and the framework for displayng these counters has been in NetBSD for well
over 10 yers, yet, all of these counters are ifdefed out of general use and
hence unavailable to those users who use generic kernels, or who didn't
happen to pursue what those EVENT_COUNTERS ifdefs meant in the various
drivers.  Is there a reason all of these counting facilities are not
enabled by default in GENERIC kernels?  Does using these counters impose such a
performance penalty that general use was deemed too crippling?
        I think having these counting facilities available to the general
NetBSD user would be a huge win.  As such, I propose to embark on a project
to enable such counters in GENERIC kernels so that users may view these
extended stats about their network performance.  I'll note that event
counters seem to be enabled in the NetBSD-5.x kernels to do things like
count the number of tlb flushes, ioapic interrupts and the like.  If it
works for those high frequency items, why not enable it for network
drivers?
        My thought is to define a generic option, say
ENABLE_INTERFACE_COUNTERS, which would turn on these counters for drivers
which had been tested and were known to work.  Then, for each driver,
enable its counting options and test.  Finally, once local testing was
complete, check in a change for that driver which would hook it to the
general cunting option, and, as a result, add that driver's counting
capabilities to the GENERIC kernel.  Is there a reason this should not be
done?  Are there caveats that I need to be aware of?  Having event stats on
network interfaces would be a huge bonus for NetBSD's usability and, since
it looks like it's almost there, why not make it happen?
        thoughts?  Objections?  Encouragement?

-thanks
-Brian


Home | Main Index | Thread Index | Old Index