[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



> 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.
Clean support for variable-sized requests is also quite important
(whether netchannel1-style chaining of fixed size requests or true
variable-size requests).  This is even more useful for SCSI, because
things like the sense buffer size can vary quite dramatically between
requests, and sizing it for the worst case would be a very wasteful
use of ring space.

> However, this version went back to simple 1 ring architecture as same
> as VBD. We expect the performance will not be degraded because many
> transactions are distributed into multiple-rings.
I'm not quite sure what you mean here.  You currently have a single
ring per LUN; are you expecting heavy workloads to always be spread
over several LUNs?

> We would like to enhance it as second step after this version is
> merged into Xen tree, if possible.
As Ian points out, stuff in the stable trees is supposed to have a
stable ABI, which can make some changes difficult.

Of course, we might be able to declare the tree stable except for SCSI
support, but that's a bit of a change from our current model.

Steven.

Attachment: signature.asc
Description: Digital signature

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.