On Wednesday 09 July 2008 00:15, Roland Dreier wrote: > Looking at this in the context of what's queued already -- would it make > sense to expose this via the protocol counters stuff that went in for > iWARP? > > - R. The firmware diagnostic counters are not IB-protocol counters -- they are low-level device-specific (i.e., ConnectX-specific) counters.
As such, I think the code to implement them belongs in the low-level driver layer. The problem here is that the sysfs counter file names are specified in the core layer (core/sysfs.c) via the IW_STATS_ENTRY macro at compilation time. 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. Despite the great code similarity, I think it is preferable to leave the firmware diagnostic counters in the mlx4 layer at this point. - Jack _______________________________________________ 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
