Re: [Xen-devel] xen-vbd interface (segment size expansion) - FreeBSD host have it.

[Justin Gibbs <justing@xxxxxxxxxxxxxxxx>]

On Oct 18, 2012, at 8:50 AM, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
 wrote:

> On Thu, Oct 18, 2012 at 01:59:36AM +0000, Duan, Ronghui wrote:
>> Hi, I am back from a long holiday. Sorry for the delay replay.
>>> I was wondering how the protocol you developed works when it comes to
>>> migration to a host that does not support the new features?
>>> 
>> For my part, when VM migrate to a host which do not support larger segments, 
>> frontend will fall back to use original protocol with old-segments 11.
>> 
>>> Specifically how do deal with a guest which tries to replay in progress I/Os
>>> that do not fit within the old-segment size (11)?
>> The in-progress bio which have larger segments > 11 will receive an io 
>> error. I do not find a better way to handle it yet.
> 
> Justin, how did you guys handle it in FreeBSD? Or is it dependent on
> the backends always supporting these large segments?

The current API forces I/Os larger than 44k to get chopped up in
order to transit blkif.  The ability to negotiate a larger blkif
request size just means that you can sometimes reduce the amount
of "scatter-gather" work performed by the driver.  You must still
deal with the fact that a logical I/O submitted to blkfront may
need to be broken up, or may not completely fit within the size of
the negotiated ring.  Upon reconnect, the newly negotiated parameters
are in effect and reissued I/Os are subject to the rules that apply
to that connection.

I'd have to go review the FreeBSD blkfront driver to see if it
handles correctly all of the issues that arise with a ring that
shrinks (e.g. it may assume that an I/O will fit within an empty
ring), but there is certainly no technical reason that these issues
can't be addressed.

--
Justin


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