[ofa-general] IB performance stats (revisited)

Hal Rosenstock halr at voltaire.com
Wed Jun 27 14:44:36 PDT 2007


On Wed, 2007-06-27 at 17:26, Jason Gunthorpe wrote:
> On Wed, Jun 27, 2007 at 05:13:40PM -0400, Hal Rosenstock wrote:
> 
> > > - The kernel periodically fetches the performance stats and aggregates
> > >   them into a 64 wrapping counter. The kernel sends PMA mads into the
> > >   mellanox firmware to read and reset the counters
> > > - The new 64 bit stats are exported via sysfs/proc/whatever as
> > >   wrapping counters
> > > - When a PMA packet comes in the kernel services it rather than
> > >   passing it on to the chip firmware.
> > 
> > In this way, both 32 and 64 bit counters could be presented by the PMA
> > but how would it know when the a counter has maxed out in terms of the
> > PMA and how would a remote clear be handled ?
> 
> Each time the counter is cleared

So it doesn't matter whether the clear is local (from Linux) or remote
(from IB), right ?

>  the kernel would store the 64 bit
> value as the 'last PMA counter'. Then the calculation is just
> 
> if ((current - stored) >= saturation)
>   return saturation;
> return current - stored;
> 
> After 2**64 counts the saturation computation will stop working. It
> would take 24 years of constant maxed out data transfer for a 12x QDR
> link to wrap a 64 bit dword byte counter.

Is that even for the 4 octet counts ? (I didn't calculate this out).

> A nice side benifit would that linux drivers could present a
> consistent PMA interface with new extended 64 bit counters even with
> older hardware.

Indeed.

The question may now be how to get from where we are today to this
model.

-- Hal

> Jason




More information about the general mailing list