From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: xen-vbd interface (segment size expansion) - FreeBSD host have it. Date: Fri, 19 Oct 2012 10:14:53 -0400 Message-ID: <20121019141453.GL26830@phenom.dumpdata.com> References: <20120817172838.GA3515@phenom.dumpdata.com> <61DFA8800400A143A5A7C5E136A726DC5F867490@reactor.sldomain.com> <20120925152600.GA967@phenom.dumpdata.com> <20121018145030.GD19782@localhost.localdomain> <61DFA8800400A143A5A7C5E136A726DC5F9D0C67@reactor.sldomain.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <61DFA8800400A143A5A7C5E136A726DC5F9D0C67@reactor.sldomain.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Justin Gibbs Cc: "Duan, Ronghui" , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On Thu, Oct 18, 2012 at 03:34:27PM +0000, Justin Gibbs wrote: > On Oct 18, 2012, at 8:50 AM, Konrad Rzeszutek Wilk > 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