[ofw] Adding Performance Counters support for WinOF

[Moshe Haim]

So it seems that with the new libraries I will be able to access the
information directly (through API) - which will be easier for me.

However, the issue of the counters filling up so fast remains as is.
I have made a few additional checks and updated my firmware. The
counters on windows are counted in 4 bytes increments. I.e if my counter
shows 0x64 then it means that 100*4 (400) bytes were transferred.

However, when I checked the Linux system using perfquery I am getting a
totally different ratio.
It appears that the counters there are still 32-bit wide, but the
increments are around 1MB - so if my counter shows 0x64 it means ~100MB
of data were transferred.

Can someone please tell me:
1. Where does this difference come from?
2. Since we are talking about 10Gbit (and more) transfer rates, why do
the counters count in (4x)bytes? Since most chances they will fill up
very fast (as seen)

Thanks,
Moshe.


-----Original Message-----
From: Sean Hefty [mailto:sean.hefty at intel.com] 
Sent: Thursday, January 15, 2009 8:33 PM
To: Moshe Haim; ofw at lists.openfabrics.org
Subject: RE: [ofw] Adding Performance Counters support for WinOF

>I further discussed it with my manager who worked with the Linux
version
>and I was told that on Linux there was a problem with perfquery since
it
>was neither thread nor process safe - i.e. calling it concurrently from
>2 or more threads/processes would crash.
>In addition, I can only assume perfquery is an executable.

perfquery is an executable.  I'm not sure what's meant about being
thread or
process safe, since it's a stand alone program.

>I also assume that perfquery uses one of the more "lower levels" dlls
>mentioned below in order to get the performance counter information
>(libibumad?).

perfquery sends MADs that query the performance counters.  The counters
are
returned in a MAD.  The MAD format and behavior is defined by the IB
spec.

>To be more concrete, if I'd want to directly access the counter
>information I'll simply need to link my project against that DLL and
>call an API method - is that assumption correct?

You can send and process your own MADs.  In this case, you can write to
any of
MAD libraries.

- Sean