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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 08.02.12 at 23:00, "Justin T. Gibbs" <justing@xxxxxxxxxxxxxxxx> wrote:
> 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.

No, that's not what I intended to propose. Instead, I'd see the
frontend write consistent values (and best always write both node
flavors) if at least one of the protocols is supported by the backend.

I'm only suggesting that the frontend should not use either multi-
page rings at all if it finds both backend node flavors present yet
having inconsistent values (i.e. absence of either [but not both]
values does *not* count as inconsistent, and hence a single absent
node not implicitly assuming its default value).

> 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.

For the moment I decided to only have the frontend handle both
flavors in our implementation. That way, not question about
inconsistent values published by the backend can arise.

Jan


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