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 9, 2012, at 2:15 AM, Jan Beulich wrote:

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

Then your desire is already allowed by the maximum values for
these nodes in the current spec.  I will clarify the notes section to
say that, if both node types are supported by a driver, both node
types should be written with consistent values.

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

I think that's a perfectly reasonable behavior, but not the only
reasonable behavior.  If I need to write a front or back end driver that
is more tolerant in order to have optimum performance with an
existing driver that I do not control, the spec should allow me to do this.

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