All of lore.kernel.org
 help / color / mirror / Atom feed
From: Harry Butterworth <harry@hebutterworth.freeserve.co.uk>
To: "Ronald G. Minnich" <rminnich@lanl.gov>
Cc: Eric Van Hensbergen <ericvh@gmail.com>,
	Mike Wray <mike.wray@hp.com>,
	xen-devel@lists.xensource.com,
	Eric Van Hensbergen <ericvh@users.sourceforge.net>
Subject: Re: Re: Interdomain comms
Date: Sat, 07 May 2005 18:17:07 +0100	[thread overview]
Message-ID: <1115486227.4082.70.camel@localhost> (raw)
In-Reply-To: <Pine.LNX.4.58.0505071009150.13088@enigma.lanl.gov>

On Sat, 2005-05-07 at 10:15 -0600, Ronald G. Minnich wrote:
> 
> On Sat, 7 May 2005, Harry Butterworth wrote:
> > A significant difference between Plan 9 and Xen which is relevant to
> > this discussion is that Plan 9 is designed to construct a single shared
> > environment from multiple physical machines whereas Xen is designed to
> > partition a single physical machine into multiple isolated environments.
> 
> this is not in my view germane. We're proposing using 9p as the low level 
> interdomain protocol for xen. 9p stands alone from plan 9. Both Eric and I 
> have felt for some time that this would work well, and I'm pretty strongly 
> convinced that it would work better than what we have now for the various 
> devices. 

I agree it would work well, definitely better than the current code, but
I don't think it's right for Xen because it precludes the kind of
optimisations that are relevant to Xen but not Plan 9.

Eric mentioned adding scatter/gather type semantics to the 9P protocol
which would get you half-way to what I was proposing and start to look
similar to the remote buffer reference concept in that you pass around
references to the bulk data instead of the data itself but you still
wouldn't get the ability to manipulate the meta-data of a request in a
stack of I/O applications and then do a direct transfer of the bulk data
from the source to the target.

Of course, if you modify the 9P protocol enough then you can make it a
superset of what I was proposing but I think my API proposal captured
the essence of what was required at the low level without complicating
the description with the higher level organisation aspects of the
protocol.

> 
> Your 1000 machine example is very interesting, however. I do know that 
> some folks who worked on the IBM hypervisor had a lot of concerns about 
> the page flipping done in the xen network FE/BE drivers, and I wonder if 
> their concerns would apply to your proposed implementation -- I wish we 
> could find a way to hear from them. 

Rusty and I exchanged some mail about the page flipping and I think
Rusty demonstrated that their concerns were unfounded.  Perhaps he can
comment.

In any case, my proposal decouples the IDC API clients from the actual
memory management implementation so different page-flipping behaviours
could be evaluated without requiring code changes in the clients.

Harry.

  parent reply	other threads:[~2005-05-07 17:17 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-05 15:18 please help: initialize XEND for my debug-FE/BE.c Aggarwal, Vikas (OFT)
2005-05-05 20:37 ` Harry Butterworth
     [not found]   ` <427B20B9.1010101@hp.com>
2005-05-06 12:14     ` Interdomain comms Harry Butterworth
2005-05-06 13:39       ` Mark Williamson
2005-05-06 16:04       ` Ronald G. Minnich
2005-05-06 16:49         ` Eric Van Hensbergen
2005-05-06 23:13         ` Harry Butterworth
2005-05-07  0:19           ` Eric Van Hensbergen
2005-05-07 13:26             ` Harry Butterworth
2005-05-07 14:57               ` Eric Van Hensbergen
2005-05-07 16:15               ` Ronald G. Minnich
2005-05-07 17:10                 ` Keir Fraser
2005-05-07 21:22                   ` Eric Van Hensbergen
2005-05-07 17:17                 ` Harry Butterworth [this message]
2005-05-07 21:29                   ` Eric Van Hensbergen
2005-05-07 22:11                     ` Harry Butterworth
2005-05-08  0:57                       ` Eric Van Hensbergen
2005-05-08  8:19                         ` Andrew Warfield
2005-05-08 15:27                           ` Eric Van Hensbergen
2005-05-10  8:31                           ` Mike Wray
2005-05-10 10:09                             ` Andrew Warfield
2005-05-10 14:30                               ` Mike Wray
2005-05-10 14:51                               ` Harry Butterworth
     [not found]                                 ` <eacc82a405051008243195164c@mail.gmail.com>
2005-05-10 15:26                                   ` Andrew Warfield
2005-05-10 16:42                                     ` Harry Butterworth
2005-05-08  8:36                         ` Harry Butterworth
2005-05-08 16:18                           ` Eric Van Hensbergen
2005-05-08 17:48                             ` Harry Butterworth
2005-05-06 16:57       ` Nivedita Singhvi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1115486227.4082.70.camel@localhost \
    --to=harry@hebutterworth.freeserve.co.uk \
    --cc=ericvh@gmail.com \
    --cc=ericvh@users.sourceforge.net \
    --cc=mike.wray@hp.com \
    --cc=rminnich@lanl.gov \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.