All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Justin Gibbs <justing@spectralogic.com>
Cc: "Duan, Ronghui" <ronghui.duan@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: xen-vbd interface (segment size expansion) - FreeBSD host have it.
Date: Fri, 19 Oct 2012 10:14:53 -0400	[thread overview]
Message-ID: <20121019141453.GL26830@phenom.dumpdata.com> (raw)
In-Reply-To: <61DFA8800400A143A5A7C5E136A726DC5F9D0C67@reactor.sldomain.com>

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@oracle.com>
>  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

      reply	other threads:[~2012-10-19 14:14 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <A21691DE07B84740B5F0B81466D5148A23BE55DE@SHSMSX102.ccr.corp.intel.com>
     [not found] ` <20120817172838.GA3515@phenom.dumpdata.com>
     [not found]   ` <A21691DE07B84740B5F0B81466D5148A23BE8F48@SHSMSX102.ccr.corp.intel.com>
     [not found]     ` <61DFA8800400A143A5A7C5E136A726DC5F867490@reactor.sldomain.com>
2012-09-25 15:26       ` xen-vbd interface (segment size expansion) - FreeBSD host have it Konrad Rzeszutek Wilk
2012-10-18  1:59         ` Duan, Ronghui
2012-10-18 14:50           ` Konrad Rzeszutek Wilk
2012-10-18 15:34             ` Justin Gibbs
2012-10-19 14:14               ` Konrad Rzeszutek Wilk [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20121019141453.GL26830@phenom.dumpdata.com \
    --to=konrad.wilk@oracle.com \
    --cc=justing@spectralogic.com \
    --cc=ronghui.duan@intel.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.