[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 Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |