On Tue, Nov 01, 2011 at 07:23:52PM +0200, Or Gerlitz wrote: > Jason Gunthorpe <jguntho...@obsidianresearch.com> wrote: > > Is there any reason to expose the 32 and 64 bit version of the same > > counter? That seems needless. Emit the largest version available and > > prepend 0's to fill out to the available width so that userspace can > > know the counter size. > > Basically, the approach you suggest seems fine for IBoE which is > pretty new, however, > > the problem is that the 32 bit counters exists from kind of day one > AND have the same semantics either if returned through sysfs or > through perfquery and alike mad based apps. > In other words around IB there should be some legacy which exists > today, and I don't think it would be wise to touch that area such that > the 32 bit counters become embedded in 64 bit numbers, thoughts?
I don't see a problem with having a sysfs counter file being extended to return a 64 bit number.. I think that is within the purvue of acceptable changes. Shame the counter wasn't exported as hex though - makes it harder to signal if it is 32 or 64 bit. Frankly, exporting these PMA counters as saturate on maximum via sysfs is pretty useless. Does anyone actually use them aside from a few scripts? What would be useful is free running 64 bit sysfs counters that are independent and not reset by PMA activity. Like all the other Linux networking counters. That would be great. I hope that is what is done for IBoE? Unifying the counters to be semantically the same on IB and IBoE seems like a very good idea. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
