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

[Jared Rhine <jared@xxxxxxxxxxx>]

> > 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.

Which is a fair argument, though not raised in Ron's earlier objections.

It's certainly not unreasonable to have a direct TCP listener as well as
a UDP listener in the same daemon.  Though single-purpose daemons are
better for maintainability and robustness, the minor extra code to have
both Unix domain and TCP branches is straightforward.

I do think that the "no TCP is my lightweight dom0" people should be
supported, though I'm not personally one of them.  So a Unix domain
listener seems like it should be available through xcs.  Making those
people build and maintainer and _alternative_ multiplexing switch isn't
good for anyone.

I now favor xcs supporting both listening approaches, though I'm not
volunteering code.  I'd rather let the experts sort out the right
layering and then contribute on the tools that use the final mechanism.

> I'm not sure I understand how this could create a performance problem. 
> I simply don't know that much about cluster-performance and am very
> curious :-)

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?

-- 
Jared Rhine <jared@xxxxxxxxxxx>



-------------------------------------------------------
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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel