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/
Home Products Support Community News


[Xen-devel] [RFC][Re: Xen Roadmap proposal] Grant table sockets

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] [RFC][Re: Xen Roadmap proposal] Grant table sockets
From: Michael LeMay <mdlemay@xxxxxxxxxxxxxx>
Date: Thu, 20 Jul 2006 08:17:00 -0400
Delivery-date: Fri, 21 Jul 2006 01:28:02 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Here's another general comment for discussion...

The bottom of page 18 in the Xen Roadmap proposal recommends considering
how to "export byte stream
(TCP) data between domains in a high performance fashion."  For
communications that occur between domains on a single physical machine,
it would seem logical to setup a new address and protocol family within
Linux that could be used to create and manipulate stream sockets via the
standard interfaces (I'm focusing on Linux at this point, although
similar adaptations could be made to other kernels).  Then, behind the
scenes, the Xen grant tables could be used to efficiently transfer
socket buffers between the domains.  This should involve much less
overhead than directly connecting two network frontends or performing
other optimizations at lower layers, since it would truncate the
protocol stack and avoid unnecessary TCP-style flow control protocols. 

An enhancement such as this could help to eliminate the network
dependence of some Xen management applications, particularly those that
rely on XML-RPC to communicate.  For example, xm currently uses a UNIX
domain socket to communicate with Xend, which introduces an artificial
requirement that xend and xm be running in the same domain.  Once XenSE
gains traction and management utilities are scattered across multiple
domains, UNIX domain sockets will no longer be adequate.  Under this
scheme, stream sockets to specific domains could easily be constructed,
without regard for the network configuration on the system.

One important detail that I haven't yet resolved is how to address
inter-domain sockets.  Of course, the most important component in the
address for each socket would be the domain ID.  However, some sort of
port specification or pathname would also be necessary.  I'm not sure
which of those options would be appropriate in this case.  Port numbers
would be consistent with TCP and would probably ease the task of porting
applications based on TCP, but pathnames are more consistent with the
UNIX domain sockets used by xm and xend.  Perhaps we could provide both,
using two address families associated with the same protocol family?

What other ideas have been floating around on how to accomplish
byte-stream transport between domains?  Are any concrete efforts to
provide this functionality currently underway?  Thanks!

 -- Michael

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>