Re: [PATCH] xenctld - a control channel multiplexing daemon

[Anthony Liguori <aliguori@us.ibm.com>]

On Mon, 2005-01-24 at 10:55, Jared Rhine wrote:
> > > Again, this is not an issue of esthetics, it's an issue of measured 
> > > performance. 
> > 
> > Where's the performance issue?
> 
> I think Ron was suggesting that the dual handoff of the data between the
> UDP listener and the TCP listener would be foolish and avoidable and
> inarguably is a measurable throughput degredation over a direct TCP
> processing loop.

You're not going to have a direct listener though on TCP.  I think you
mean unix domain sockets too instead of UDP.  The current message
passing architecture assumes the messages are originating from the
native architecture.

They do not take into account things like endianness into
consideration.  They certainly don't security into account at all.  To
export a proper TCP interface requires a higher level protocol.  The TCP
interface will have to do a certain amount of work to take these things
into account.

I think we all agree that we need a TCP interface.

The only real question is whether you export a lower level protocol
interface via something like domain sockets.  Domain sockets are
extremely fast on most platforms (usually reducing to something like a
memcpy).  Considering the message size here I do not think you can make
a performance argument for having a TCP daemon go through a domain
socket.

If we agree that we need a higher level protocol for TCP, then it
becomes pretty apparently that there's going to be desire for multiple
protocols.  Maybe a less security conscious protocol for isolated
clusters (like xcs implements right now) verses a more hardened protocol
for enterprise usage.

Using multiple daemons here becomes a no-brainer.  You just start the
appropriate daemon for whatever protocol you wish to export.  Properly
architected, multi daemons could even be run simultaneously to support
multiple sets of control tools.

> Ron, is your performance concern because large clusters need to pass a
> very high volume of control messages?  For any low-volume situation,
> this unix domain/TCP argument is a non-issue, mostly?

I have a feeling that the concern is that there's a general fear that
more daemons == more resource usage == more administrative overhead.  I
don't think this is true though.  I think it simply depends on how
things are architected.

-- 
Anthony Liguori
Linux Technology Center (LTC) - IBM Austin
E-mail: aliguori@us.ibm.com
Phone: (512) 838-1208




-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl