[uml-devel] RE: [uml-user] [PATCH net-tools] debug improvements

[Mooneer S. <mo...@ea...>]

[sent to user-mode-linux-devel as well]

I'm messing with the network code at the moment. I noticed that
the virtual ethernet driver makes a TCP connection to localhost.
How much less overhead would be incurred if this was changed to
use Unix sockets instead (e.g. like /tmp/mysql.sock for MySQL)?

Right now I made a few hacks to both the user-mode utilities and
the test11 kernel to use Unix sockets instead of TCP/IP.
Basically the kernel opens /tmp/tapx for each virtual ethernet device
it detects, instead of opening a connection to localhost. The user-mode
utilities make sockets on /tmp/tapx and use those instead of TCP/IP. This
should cut down on overhead. Once I see how stable or unstable it
is I'll make the diffs and send them to Jeff and/or the list.

-----Original Message-----
From: use...@li...
[mailto:use...@li...]On Behalf Of
Rodrigo Barbosa (aka morcego)
Sent: Tuesday, December 05, 2000 12:32 PM
To: Jeff Dike
Cc: use...@li...
Subject: Re: [uml-user] [PATCH net-tools] debug improvements


On Tue, Dec 05, 2000 at 01:19:20AM -0500, Jeff Dike wrote:
> It's up to Jim Leu, but I would be inclined not to take this patch.  The
> reason is that you're chasing a big problem, and big problems have big
fixes
> (in the sense that you fix it and it makes a big difference).  So, if I
were
> you, I'd ignore all this little stuff until you find the real bug.  Also,
by
> fixing little things, you run the risk of getting enough small
improvements to
> add up to something that's barely acceptable.  Then you stop chasing the
real
> problem because things are now sort of OK.

I don't necessarily agree with you. I have seen big problems that only
needed small fixes.
But in this particular case, we only think that it's just one big problem.
But we can have a series of small problems that looks just like a big one.

> I think this particular patch is also a bad idea because it's good to be
able
> to turn on debugging in the standard executable with a command line
option,
> and not have to recompile it.  And if debugging is the default, as you
have
> it, then hardly anyone is going to turn it off, so the ifdefs aren't doing
> anything except cluttering the code.

Well, my proposal was to minimize changes. The code didn't have suport
for a debug flag, the debug option was hardcoded and turned on by default.
What I'm planning to the future (don't scream or cluebat me, please), is to
use multithreading to have debugging with very small performance hits.
I keep the main thread for routing, and another one for debugging, so I can
have async debug, causing minimal performance hit.

> I also have a hard time believing that those tests make any kind of
> performance difference.  And if it is measurable, then we're back to my
> argument above.

They have an effect, yes. Very small. But I'm not yet sure that we are
dealing
with just one big problem here.

> Cleaning up excessive output might be a good idea, but all of the
fprintf's
> that you've ifdefed look like fairly rare occurrences.

Not so rare. And fprintf is a samewhat costy instruction.

> In the interest of not being totally negative, I have to say that moving
that
> fork does look like a good idea.

Thanks.
And no, I don't think you are being totaly negative. Totaly negative is like
some people that simply refuses a patch, without telling why they did.
Once you explained your reason, I can work to improve it, remove problematic
points, and maybe come up with something better.