Re: [Xen-devel] [PATCH 4 of 5] blkif.h: Document the RedHat and Citrix blkif multi-page ring extensions

["Justin T. Gibbs" <justing@xxxxxxxxxxxxxxxx>]

On Feb 3, 2012, at 9:12 AM, Jan Beulich wrote:

> > On 03.02.12 at 16:19, Justin Gibbs <justing@xxxxxxxxxxxxxxxx> wrote:
> >
> > However, if this is the rule, both types of "max ring size" values
> > are "in effect" even if a back-end does not provide them both.  So
> > how do you resolve the conflict?  A fully interoperable front should
> > allocate the largest possible ring and advertise that size through
> > both mechanisms in a fully consistent manner. That's what I was
> > trying to indicate by writing the spec this way.
> 
> Hmm, I would think a fully compatible frontend should bail (revert to
> single page ring) on inconsistent max-ring-pages and
> max-ring-page-order, if both are provided by the backend. The limit
> for ring-pages should always be max-ring-pages, while the one for
> ring-page-order should always be max-ring-page-order. Any mixture
> is an error, unless both values are consistent with one another.
> 
> Jan

Mandating that a front-end publish inconsistent values to the
XenStore would be a mistake.  Having the front-end only publish the
set of nodes that are recognized by the back-end just adds code
complexity with no associated increase in functionality.  You
actually would lose the ability to tell that the driver supports
both schemes.

To clarify what I mean by that, consider the current state of
back-ends in the world.  They fall into 1 of 4 camps:

 1. No multi-page ring support
 2. "Citrix style" multi-page ring support.
 3. "Red Hat style" multi-page ring support.
 4. "Both styles" multi-page ring support.

In cases 1-3, one or both of the max-ring-page* nodes is not present.
Per the currently proposed spec, this means that these nodes have
their default values.  You seem to be advocating that the front-end
write the default values into its corresponding node.  For cases 2
and 3, this would lead to contradictory values in the XenStore (e.g.
ring-page-order=0 and ring-pages=4).  This will not confuse the
back-end, but could confuse a human.

For case 4, the back-end must publish both node types even though
the front-end may not look at both.  Since we can't avoid having
both nodes, it seems reasonable to allow a front-end to publish
them both too.  It also avoids the additional logic to test against
back-end node presence.

With all that said, I believe the spec should indicate that a
fully-interoperable implementation should publish both nodes with
values that match the allocated ring size.  The tolerance level for
a back-end publishing inconsistent nodes should be left to the
implementation.

--
Justin


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel