Andre Oppermann wrote: > > Benchmark the driver. > > > > If it's fast, it doesn't collect the statistics. > > Come on, this is bullshit. whatever++ hardly makes any difference. > There are other places where way more cycles are wasted for less.
You removed my "8-)" by truncating my statement, and seperating it out. However, if you're going to be insistant, my statement was really like foam rubber duct taped to an aluminum baseball bat: a core of truth wrapped in humor, so it didn't hurt as much. Without the atomic increment code that John Baldwin and Julian Elisher have asked to be adopted time and again, each place you increment has to lock, increment, then unlock the interface statistics structure. Similar locks occur on the global statistics, which are contended between all interfaces, rather than aggregated out of per interface statistics, with no locking whatsoever (like "ps", they are a snapshot of system state; the only accuracy needs to be in their incrementing, not in their instantaneous value). The upshot is serialization of routing and/or multicast on multiple interface systems. You end up having to implement increment locking in any case, if you insist on your snapshot, even for a single interface, have inter-element consistency for the aggregate of all values for a given interface (you must write lock so that writing respects the read lock, since writes are per elemenet, and reads are per aggregate). This is particularly true for "bad packet" counters, where the decision about what constitutes a bad packet is most often made by higher protocol layers, and thus is not intrinsically "per interface" -- worse, they run at NETISR in 4.x, and are expected to run in an interrupt thread, in 5.x. Getting rid of NETISR entirely (*not* replacing it with interrupt threads running the stack) would get rid of the contention, in that there would be implicit locking of the structure, were it per interface. You'd still need to aggregate it for global stats (e.g. the output of "netstat -s"), but, per above, that would not require locking, since it's a read-only operation, and is statistical in natures. For statistics, read locking implies write locking which implies locking on every update operation, even when the vast majority of times there is no possiblity of contention, because no one really cares about the stats values, for the most part. If you insist on exactitude, then you end up seperately serializing all statistics updates -- after all, statistics are gathered as the result of conditions which are rarely simultaneously handled in the code. Most of the stuff the original post wanted to monitor is not really defined for STD-0050 (RFC-1643), RFC-2665 or RFC-3201. Further, interface statistics are peculiar to the abstract concept "interface", and should have nothing whatsoever to do with the driver. If there is explicit driver support required, then there is an intrinsic problem, in that the MIB elements in question are not uniform across drivers for real hardware reasons, not just because someone forgot to add them. Probably, it would be good to implement them at a higher "interface layer", on top of all drivers. Bill Paul and Archie Cobbs would bot be good people to involve in any discussion, but to me, it makes no sense to modify individual drivers to resolve the original issue, rather than writing common code once, in lieu of replicating (hopefully) identical code in a grundle of drivers. The real answer should have been "For what purpose are these statistics to be gathered?", particularly since a many of them are in fact not RFC mandated for Interfaces, and are really only valuable in particular application domains (and may have their own MIBs for those domains, e.g. Frame Relay, DSL, or 802.12, etc.. So if you want to be picky, let me change my answer: For what purpose are these statistics to be gathered? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
