Well, here is the patch I promissed.
It's actualy much better then the last one (please, destroy it if you still
have a copy :-)).
Lemme tell you a little about it.
First, we now have 3 situations instead of 2.
1st: The debuging code is not compiled in
2nd: The debuging code is compiled in and is deactivated
3rd: The debuging code is compiled in and is activated
In any of the 3 situations, I have noticed an improvement of at least 20%
on the network performance compared to the original code (with debuging).
Do, what we did to make the debuging hit much smaller ?
Well, we use threads :-) The main process just takes care of the
routing. When it wants to write debug, it doesn't do it itself, but
instead calls a function debug().
While all the routing is happening, we have a thread running in
paralel (of course :-), with low priority (nice(2)), taking care of
the debug output job (which is farly slow). The funcion debug() just
write to a pipe (nonblocking, or else we would not have any performance
gain), and the debug thread reads from there.
Also we introduced the concept of the UMLNETDEBUG environment variable.
That it does is to instruct the um_eth_net_tool application to start or
not the debugging facility. Quite simples. If the variable is defined,
we start debugging. If not, we don't.
Anyway, the patch is attached bellow.
Rodrigo Barbosa (morcego) - rodrigob@...
Conectiva R&D Team - http://distro.conectiva.com.br
"Quis custodiet custodes?" - http://www.conectiva.com
Get latest updates about Open Source Projects, Conferences and News.