Re: [Xen-devel] [Patch 3/7] pvSCSI driver - Keir Fraser - com.xensource.lists.xen-devel

15 messages in com.xensource.lists.xen-develRe: [Xen-devel] [Patch 3/7] pvSCSI dr...

From	Sent On	Attachments
Jun Kamada	18 Feb 2008 02:11	.patch
James Harper	18 Feb 2008 17:30
James Harper	18 Feb 2008 17:42
Steven Smith	27 Feb 2008 03:16
Ian Pratt	27 Feb 2008 04:23
Jun Kamada	27 Feb 2008 20:27
Ian Pratt	28 Feb 2008 01:22
Keir Fraser	28 Feb 2008 01:56
Steven Smith	28 Feb 2008 04:06
James Harper	28 Feb 2008 05:07
Mark Williamson	28 Feb 2008 07:31
Steven Smith	28 Feb 2008 08:13
Jun Kamada	28 Feb 2008 15:55
Steven Smith	29 Feb 2008 05:46
Jun Kamada	03 Mar 2008 01:58

Subject:	Re: [Xen-devel] [Patch 3/7] pvSCSI driver
From:	Keir Fraser (Keir...@cl.cam.ac.uk)
Date:	02/28/2008 01:56:16 AM
List:	com.xensource.lists.xen-devel

On 28/2/08 09:23, "Ian Pratt" <Ian....@eu.citrix.com> wrote:

In fact, previous version of pvSCSI driver used 2 rings for frontend to backend and backend to frontend communication respectively. The backend also queued requests from frontend and released the ring immediately. This may be very similer concept to the Netchannel2.

Cool, that sounds better. Did you still have fixed length command structs, or allow variable length messages? (I'm very keen we use the latter)

The netchannels2 model is 16-byte granularity 'cells' in the comms rings. A descriptor can span multiple cells and its length is implicitly known from its type (which resides in the first byte of the first cell). Individual cells do not wrap in the ring (since the ring is a multiple of 16 bytes in size) but multi-cell descriptors may wrap. Further, netchannel2 allows descriptors to be chained into longer messages. I think Jose is going to use the msb of the descriptor-identifier byte for this purpose.

We've toed-and-froed on details of this protocol a few times, so I've cc'ed Jose in case the current state of the design is different from what I believe.

-- Keir