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

Re: [Xen-devel] RFC v1: Xen block protocol overhaul - problem statement (with pictures!)



>>> On 18.12.12 at 15:31, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote:
> The A) has two solutions to this (look at
> http://comments.gmane.org/gmane.comp.emulators.xen.devel/140406 for
> details). One proposed by Justin from Spectralogic has to negotiate
> the segment size. This means that the âstruct blkif_sring_entryâ
> is now a variable size. It can expand from 112 bytes (cover 11 pages of
> data - 44kB) to 1580 bytes (256 pages of data - so 1MB). It is a simple
> extension by just making the array in the request expand from 11 to a
> variable size negotiated.

Iirc this extension still limits the number of segments per request
to 255 (as the total number must be specified in the request,
which only has an 8-bit field for that purpose).

That's one of the reasons why for vSCSI I didn't go that route,
but rather allowed the frontend to submit segment information
prior to the actual request (with the trailing segment pieces, if
any, being in the request itself).

Jan

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

 


Rackspace

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