[Fwd: Re: [PATCH] skeleton frontend/backend examples and a deadlock]

[Fwd: Re: [PATCH] skeleton frontend/backend examples and a deadlock]

[harry]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: Forwarded message - Re: [Xen-devel] [PATCH] skeleton frontend/backend examples and a deadlock --]
[-- Type: message/rfc822, Size: 4012 bytes --]

From: harry <harry@hebutterworth.freeserve.co.uk>
To: Mark Williamson <mark.williamson@cl.cam.ac.uk>
Subject: Re: [Xen-devel] [PATCH] skeleton frontend/backend examples and a deadlock
Date: Thu, 03 Nov 2005 11:30:00 +0000
Message-ID: <1131017400.6087.50.camel@localhost.localdomain>

On Thu, 2005-11-03 at 02:17 +0000, Mark Williamson wrote:
> A few random questions:
> 
> * Does XenIDC have any performance impact?

I expect so :-)  The slight extra complexity might make it go slower or
alternatively, because all the common code is in one place (so when you
optimise it you improve all the drivers) it might make it go faster :-)

The only think I can think of which is non-optimal about the design of
the API from a performance perspective is that a network transparent
implementation wouldn't easily be able to couple the transaction
completion to the completion of a bulk data send.  This isn't an issue
until the IDC mechanism has to span nodes in a cluster though which is
probably a way off for Xen. The existing driver code of course has much
bigger problems with network transparency.

The implementation probably needs some performance tweaking to get
batching working correctly and possibly to do speculative interrupt
handling.  Unfortunately I was forced to get a couple of patents on this
stuff a while back and I'm not sure if I'm allowed to put it in.  I'll
look into it when I have the code working.

> * Can it be compatible with the current ring interface, or does it imply 
> incompatibility with the existing scheme? (i.e. is it an "all or nothing" 
> patch?)

The API implementation isn't binary compatible with the ring code in the
other drivers or the current way the store is used to set up the ring
interface but it's not an all or nothing patch because it can coexist
side-by-side with the other drivers.

The endpoint does use shared pages for a ring buffer but it shares two
pages, one from the FE and one from the BE, each read-only.  I did this
because it's a simple symmetric implementation which was the quickest
for me to implement and I think it is easy to understand.  It also has
the advantage that if the ring gets scribbled on you can point the
finger at which domain was likely to be responsible.  I'm not aware of
any security implications.

The format of the data in the ring is slightly more complicated too
because the code is generic to cope with the varying size of different
clients requests.

I use the store differently because I wanted to correctly handle suspend
resume and loadable modules.  I don't think any of the other drivers do
this correctly yet.  Not even Rusty's skeleton driver.

The API though is completely decoupled from the implementation so you
could change the underlying implementation to go back to a single page
given from the FE to the BE or anything else you like.  I doubt you'd be
able to make the implementation binary compatible with the existing code
without having some special cases in it for the existing code.

> * Will it be able to leverage page transfers?

I expect so.  I used the local/remote buffer reference abstraction for
the bulk data transfer.  You could define a local buffer reference for
memory that was intended for transferring.  This could be converted into
a new kind of remote buffer reference which could be interpreted
accordingly at the destination.  The implementation is designed to be
extended with an arbitrary number of different types of buffer
references.

I've almost finished the rbr_provider_pool which is the FE side of the
bulk data transfer mechanism.  When I send out a patch with this code in
it will demonstrate how the local and remote buffer references are used.

Harry.

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: [Fwd: Re: [PATCH] skeleton frontend/backend examples and a deadlock]

[Mark Williamson]

Another question:

XenIDC is designed to handle indirection over the network, etc, right?  Would 
it be possible to make the indirection transparent to the guest by 
implementing it in the backend?  Or would that be the job of the frontend?

It certainly seems cleaner to me to make this as transparent to the guest as 
possible - also reduces guest complexity.

Cheers,
Mark

On Friday 04 November 2005 17:06, harry wrote:

Re: [Fwd: Re: [PATCH] skeleton frontend/backend examples and a deadlock]

[harry]

On Fri, 2005-11-04 at 17:15 +0000, Mark Williamson wrote:
> Another question:
> 
> XenIDC is designed to handle indirection over the network, etc, right?  Would 
> it be possible to make the indirection transparent to the guest by 
> implementing it in the backend?  Or would that be the job of the frontend?

The API is designed to be _compatible with a network transparent
implementation_ which means that you should be able to change the
implementation to one that worked over a network without having to
change any of the clients of the API (BE or FE).

The current implementation of the API is based on xenbus and grant
tables and is restricted to a single machine.

If you wanted to make a network transparent implementation of the API
you could do it pretty much however you wanted.  I'd probably do it by
having code in both the FE and the BE since that would avoid having to
context switch to a BE domain on the FE node before going over the
network.

> 
> It certainly seems cleaner to me to make this as transparent to the guest as 
> possible - also reduces guest complexity.

You could do it all in the BE if you wanted.  In either case, you
shouldn't have to change any of the driver code.

> 
> Cheers,
> Mark
> 
> On Friday 04 November 2005 17:06, harry wrote:
>