WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Xen

xen-devel

[Top] [All Lists]

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

To: xen-devel@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] [PATCH] xenctld - a control channel multiplexing daemon
From: Jared Rhine <jared@xxxxxxxxxxx>
Date: 2005年1月24日 08:55:52 -0800
Delivery-date: 2005年1月24日 16:56:29 +0000
Envelope-to: xen+James.Bulpin@xxxxxxxxxxxx
In-reply-to: <1106584520.18665.10.camel@localhost >
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
References: <1106322956.17263.26.camel@localhost > <eacc82a4050121083937725a83@xxxxxxxxxxxxxx> <Pine.LNX.4.58.0501211016500.4841@xxxxxxxxxx> <1106337581.18070.13.camel@localhost > <Pine.LNX.4.58.0501211343530.5215@xxxxxxxxxx> <1106342088.18665.1.camel@localhost > <Pine.LNX.4.58.0501211353100.5215@xxxxxxxxxx> <1106343476.7691.91.camel@xxxxxxxxxxxxxxxx> <Pine.LNX.4.58.0501240829570.12186@xxxxxxxxxxxxxxxxxx> <1106584520.18665.10.camel@localhost >
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
> > 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
<Prev in Thread] Current Thread [Next in Thread>
Previous by Date: Re: [Xen-devel] Re: Back end domains : input desired , Tobias Hunger
Next by Date: Re: [Xen-devel] Re: Back end domains : input desired , Jan Kundrát
Previous by Thread: Re: [Xen-devel] [PATCH] xenctld - a control channel multiplexing daemon , Anthony Liguori
Next by Thread: [Xen-devel] [PATCH] xenctld - a control channel multiplexing daemon , Jared Rhine
Indexes: [Date] [Thread] [Top] [All Lists]

Copyright ©, Citrix Systems Inc. All rights reserved. Legal and Privacy
Citrix This site is hosted by Citrix

AltStyle によって変換されたページ (->オリジナル) /