All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Van Hensbergen <ericvh@gmail.com>
To: andrew.warfield@cl.cam.ac.uk
Cc: Eric Van Hensbergen <ericvh@users.sourceforge.net>,
	Mike Wray <mike.wray@hp.com>,
	Harry Butterworth <harry@hebutterworth.freeserve.co.uk>,
	"Ronald G. Minnich" <rminnich@lanl.gov>,
	xen-devel@lists.xensource.com
Subject: Re: Re: Interdomain comms
Date: Sun, 8 May 2005 10:27:43 -0500	[thread overview]
Message-ID: <a4e6962a0505080827646dba98@mail.gmail.com> (raw)
In-Reply-To: <eacc82a4050508011979bda457@mail.gmail.com>

On 5/8/05, Andrew Warfield <andrew.warfield@gmail.com> wrote:
> Hi Eric,
> 
>    Your thoughts on 9P are all really interesting -- I'd come across
> the protocol years ago in looking into approaches to remote device/fs
> access but had a hard time finding details.  It's quite interesting to
> hear a bit more about the approach taken.
>

There's a bigger picture that Ron and I have discussed, but there are
lots of details that need to be resolved/proven before its worth
talking about.  The overall goal we are working towards is a simple
interface with equivalent or better performance.  The generality of
the approach we have discussed is appealing, but we are well aware it
won't be adopted unless we can show competitive performance and
reliability.

> 
>    For the more specific cases of FE/BE comms, I think the devil may
> be in the details more than the current discussion is alluding to.
> 

I agree completely, in fact there are likely several devils unique to
each target architecture ;)  But that's just the sort of thing that
keeps system programming interesting.  These sorts of things will only
be worked out once we have a prototype which to drive into the various
brick walls.

> 
> There are also a pile of complicating cases with regards cache
> eviction from a BE domain, migration, and so on that make the
> accounting really tricky.  I think it would be quite good to have a
> discussion of generalized interdomain comms address the current
> drivers, as well as a hypothetical buffer cache as potential cases.
> Does 9P already have hooks that would allow you to handle this sort of
> per-application special case?
>

Page table and cache manipulation would likely sit below the 9P layer
to keep things portable and abstract (as I've said earlier, perhaps
Harry's IDC proposal is the right layer to handle such things).  9P as
a protocol is quite flexible, but existing implementations are
somewhat simplistic and limited in regard to more advanced buffer/page
sharing capabilities.  We are exploring some of these issues in our
exploration of using Plan 9 and 9P in HPC cluster environments (using
cluster interconnects) -- in fact, the idea of using 9P between VMM
partitions fell out of that exploration.

> 
>    Additionally, I think we get away with a lot in the current drivers
> from a falure model that excludes transport.  The FE or BE can crash,
> and the two drivers can be written defensively to handle that.  How
> does 9P handle the strangenesses of real distribution?
> 

With existing 9P implementations, defensive drivers are the way to go.
 There have been three previous solutions proposed for failure
detection and recovery with 9P.  One handled recovery of 9P state
between client and server, the other handled reliability of the
underlying RPC transport, and the third was a layered file server
providing defensive semantics.  As I said earlier, we'll be exploring
these more fully (along with looking at fail over) this summer --
specifically in the context of VMMs.

9P isn't a magic bullet here, and there will be lots of issues that
will need to be dealt with either in the layer above it, or below it.

        -eric

  reply	other threads:[~2005-05-08 15:27 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
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 [this message]
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=a4e6962a0505080827646dba98@mail.gmail.com \
    --to=ericvh@gmail.com \
    --cc=andrew.warfield@cl.cam.ac.uk \
    --cc=ericvh@users.sourceforge.net \
    --cc=harry@hebutterworth.freeserve.co.uk \
    --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.