[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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |