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


RE: [Xen-devel] [Patch 3/7] pvSCSI driver

To: "Steven Smith" <Steven.Smith@xxxxxxxxxxxxx>, "Jun Kamada" <kama@xxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [Patch 3/7] pvSCSI driver
From: "Ian Pratt" <Ian.Pratt@xxxxxxxxxxxxx>
Date: Wed, 27 Feb 2008 12:23:28 -0000
Cc: Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 27 Feb 2008 04:24:11 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20080227111628.GB26424@xxxxxxxxxxxxxxxxxxxxxxxxxx>
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>
References: <20080218190631.E758.EB2C8575@xxxxxxxxxxxxxx> <20080227111628.GB26424@xxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Ach5Mk21SKOzu47ZT4etyMhNBo1k+wAB67Zg
Thread-topic: [Xen-devel] [Patch 3/7] pvSCSI driver
> I think the current netchannel2 plan also calls for variable-sized
> messages with split front->back and back->front rings.  It might be
> possible to share some code there (although at present there doesn't
> exist any code to share).
> I'd also strongly recommend supporting multi-page rings.  That will
> allow you to have more requests in flight at any one time, which
> lead to better performance.

The PV SCSI stuff is great work and I'm very keen to get it into
mainline. However, I'd very much like to see it use the same flexible
ring structure that's being used for netchannel2. The main features are
as followed:

* A pair of rings, one for communication in each direction (responses
don't go in the same ring as per original netchannel)

* The rings are fixed in size at allocation time, but the area of memory
they are allocated in may be bigger than a page, i.e. a list of grant
refs is communicated over xenbus.

* The data placed on the rings consists of 'self describing' messages
containing a type and a length. Messages simply wrap over the ring
boundaries. The producer simply needs to wait until there is enough free
space on the ring before placing a message.

* Both the frontend and the backend remove data from the rings and place
it in their own internal data structures eagerly. This is in contrast to
the netchannel where free buffers and TX packets were left waiting on
the rings until they were required. Use of the eager approach enables
control messages to be muxed over the same ring.  Both ends will
advertise the number of outstanding requests they're prepared to queue
internally using a message communicated over the ring, and will error
attempts to queue more. Since the backend needs to copy the entries
before verification anyhow this minimal additional overhead.


Xen-devel mailing list