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

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

On Thu, Oct 18, 2012 at 03:34:27PM +0000, Justin Gibbs wrote:
> 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.

OK, so the one issue I keep on circling back to is there an benefit
of doing a seperate ring for segments - as opposed of re-using the existing
ring and just shrinking/expanding the number of segments?

I do like re-using the ring and just shrinking/expanding it b/c it
ends up being all neatly tucked inside the existing ring.

> --
> Justin

Xen-devel mailing list



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