> The firmware diagnostic counters are not IB-protocol counters -- they are > low-level > device-specific (i.e., ConnectX-specific) counters.
Hmm, I would disagree... things like "Responder - number of local length errors" seem pretty close to, say, InTooBigErrors in the IP MIB. > If we are to implement exposing these firmware counters in the core layer, > we need > a low-level driver API which would allow the low-level driver to pass to the > core > layer at run time a vector of counter names, and we would then need to do > all the > compile-time operations (DEVICE_ATTR, declaration of all the "show > functions", etc) > at run time. > It looks to me that this would be messy. For example, each "show" method is > specific to > one counter-name "file". We would then need to pre-declare (at compile > time) a group > of "show" methods whose names are the offsets, rather than the counter-name > (e.g., device_name ## "counter-1", etc.), and this would have the effect of > limiting > the max number of counters we could generate. this would be not too hard to implement in the same way as "ethtool -S" does it I guess. but I'm not keen on sticking a bunch of cryptic hardware-device-specific junk in sysfs. - R. _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
