Ulrich, > 1) Some numbers (e.g. fcp_frame_alloc_failures) are not supported by > some drivers (e.g. QLE2690) and the value read from the file is > "0xffffffffffffffff". The source seems to set this to -1, but when > reading it back it looks like unsigned. For a 64-bit counter it's > quite unlikely to read this value, but it's still possible. I agree that's messy. > 2) While statistics counters seems to be 64 bits, I've experienced a > "wrap around" at fewer bit positions (maybe like 40 bits) for the bfa > driver. I have no idea whether it's a hardware restriction or a > firmware/driver bug, however. I did my best to make sure it's not a > problem of my plugin (assuming those counters are read atomically when > using one read()) bfa has been dead for about 5 years so don't expect any fixes in that department. > My idea was (probably more universal than restricted to FC host > statistics) to provide another file (maybe named "statistics") that > lists the names of implemented statistics counters (i.e.: leaving out > those set to -1) together with the significant bits (like 32 or 64), > the type of the value (like "counter", "gauge", "boolean", "enum", > "string", etc.) > "string" would be free text (I doubt it will make sense for > statistics, but anyhow), "enum" would be single word tokens > (e.g. _not_ " NPort (fabric via point-to-point)"), "counter" would > count bytes or events (maybe a type "event_count[er]" may make sense), > and "gauge" would be a non-monotonic value like utilization... I'm not a particularly big fan of -1 reporting. But it seems that the path of least resistance is to fix the sysfs unsigned issue. -- Martin K. Petersen Oracle Linux Engineering
