[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |