[Openib-windows] RE: [PATCH] WPP support in IPoIB

[Fab Tillier]

Hi Yossi,

> From: Yossi Leybovich [mailto:sleybo at mellanox.co.il]
> Sent: Tuesday, December 20, 2005 7:12 AM
> 
> Fab
> 
> Attached is patch that enable WPP in the IPoIB module
> 
> The WPP is controlled in compilation (ENABLING_EVENT_TRACING)
> If  this Macro is enable then IPoIB will use IPOIB_PRINT to
> print to the WPP.
> otherwise, in check build it will use the the regular prints
> and in free will print nothing.

I think that we want to have WPP tracing enabled all the time, but I do want to
be a little sparing about it, since even if it's off, it's still a conditional
branch and putting it in every function entry/exit is going to be detrimental to
performance.  For IPoIB especially, performance is low enough as it is that we
should not deliberately reduce it.

I also don't really like merging debug output with WPP.  Reading through the
docs, I saw where one could redirect a WPP session to the debugger, but getting
this to work at boot-time seems like a lot more setup than just setting the
debug level to a given value and being done with it.  I'm still evaluating this,
so it may well be much easier in practice than what the docs make it out to be.

> BTW WPP can redirect its prints to the Kernel debugger or
> to WinDbg so even with traces we can use these WinDbg .
> (we used traceview and found it very powerful)
> For the patch I kept the regular IPOIB_TRACE I hope to replace
> them with IPOIB_PRINT

I think WPP and debug output are both quite useful, and we'll want to use both
as they serve different purposes.  I would like to see us use WPP tracing for
things that might be useful in the field.  Following the code path (function
entry/exit) really isn't that useful except during actual debug of the driver,
for which regular debug output is adequate.  WPP traces however should contain
information that would help diagnose issues in the field, so that a trace
gathered in the field would give us enough information to analyze issues without
needing customers to attach a debugger.  To that extent, I want to use WPP
tracing to replace the cl_perf calls throughout the code, as well as tracking
the main entry points into the drivers (and upcalls when calling a system port
driver) and any error paths.

> I suggest to move all our macros (IPOIB_TRACE ,AL_TRACE....)
> to use WPP, We can do it with simple script that will remove
> the parentheses from the macros and maybe change some formats
> type mismatches (the WPP check format string more carefully
> then print). I did it for the SDP and its not too much work.

I'm a bit weary of getting rid of the standard debug output.  Maybe we can have
two different types of WPP output, some that's always compiled in, and some
that's conditionally compiled and can be changed to regular debug output (or do
both WPP and debug output).  Getting the output redirected from WPP to the
kernel debugger, especially at boot time, seems to be more work than simply
setting the debug level.  I still need to play around with it to get first hand
experience, and if it's straight forward then I'll buy into a full conversion to
WPP and elimination of debug prints.

Thanks for sending this.  I definitely want to enable WPP in the different
drivers - having the ability to collect from multiple data sources and correlate
the results is very valuable, and WPP allows that to be done without the impact
on performance that debug output imposes.

- Fab