Re: [Xen-devel] [PATCH] vscsiif: allow larger segments-per-request values

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 07.12.12 at 22:34, Konrad Rzeszutek Wilk <konrad@xxxxxxxxxx> wrote:
> On Tue, Nov 27, 2012 at 11:37:31AM +0000, Jan Beulich wrote:
>> At least certain tape devices require fixed size blocks to be operated
>> upon, i.e. breaking up of I/O requests is not permitted. Consequently
>> we need an interface extension that (leaving aside implementation
>> limitations) doesn't impose a limit on the number of segments that can
>> be associated with an individual request.
>> 
>> This, in turn, excludes the blkif extension FreeBSD folks implemented,
>> as that still imposes an upper limit (the actual I/O request still
>> specifies the full number of segments - as an 8-bit quantity -, and
>> subsequent ring slots get used to carry the excess segment
>> descriptors).
>> 
>> The alternative therefore is to allow the frontend to pre-set segment
>> descriptors _before_ actually issuing the I/O request. I/O will then
>> be done by the backend for the accumulated set of segments.
> 
> How do you deal with migration to older backends?

As being able to use larger blocks is - as described - a functional
requirement in some cases, imo there's little point in supporting
such migration.

>> To properly associate segment preset operations with the main request,
>> the rqid-s between them should match (originally I had hoped to use
>> this to avoid producing individual responses for the pre-set
>> operations, but that turned out to violate the underlying shared ring
>> implementation).
> 
> Right. If we could seperate those two it would be solve that.
> So seperate 'request' and 'response' ring.

Yes. But that would be an entirely incompatible change, so only
suitable in the context of (as for blkif) re-designing the whole
thing.

>> Negotiation of the maximum number of segments a particular backend
>> implementation supports happens through a new "segs-per-req" xenstore
>> node.
> 
> No 'feature-segs-per-req'?

To me, a name like this implies boolean nature. Hence I prefer to
not have the "feature-" prefix.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel