|
|
|
|
|
|
|
|
|
|
xen-devel
RE: [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
should
> 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.
Best,
Ian
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|