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:48 AM, Ian Campbell wrote:

> On Fri, 2012-02-03 at 14:58 +0000, Justin Gibbs wrote:
>> On Feb 3, 2012, at 6:33 AM, Jan Beulich wrote:
>> 
>>>>>> On 03.02.12 at 06:24, "Justin T. Gibbs" <justing@xxxxxxxxxxxxxxxx> wrote:
>>>> @@ -187,6 +216,25 @@
>>>> *      The machine ABI rules governing the format of all ring request and
>>>> *      response structures.
>>>> *
>>>> + * ring-page-order
>>>> + *      Values:         <uint32_t>
>>>> + *      Default Value:  0
>>>> + *      Maximum Value:  MAX(ffs(max-ring-pages) - 1, max-ring-page-order)
>>> 
>>> Why not just max-ring-page-order. After all, the value is meaningless
>>> for a backend that only exposes max-ring-pages.
>>> 
>>>> + *      Notes:          1, 3
>>>> + *
>>>> + *      The size of the frontend allocated request ring buffer in units
>>>> + *      of lb(machine pages). (e.g. 0 == 1 page, 1 = 2 pages, 2 == 4 
>>>> pages,
>>>> + *      etc.).
>>>> + *
>>>> + * ring-pages
>>>> + *      Values:         <uint32_t>
>>>> + *      Default Value:  1
>>>> + *      Maximum Value:  MAX(max-ring-pages,(0x1 << max-ring-page-order))
>>> 
>>> Similarly here - just max-ring-pages should do.
>> 
>> This patch documents existing extensions.  For a new driver to properly 
>> negotiate a
>> multi-page ring with a Dom0 on EC2 (ring-pages) or a Citrix Dom0/guest 
>> (ring-page-order),
>> you must use the XenBus node names as I've defined them here.
> 
> Can we pick one and mark it as preferred and the other deprecated or
> similar? Perhaps backends will have to support both for the foreseeable
> future but we should make it possible for frontends to just pick one if
> that's what they want while nudging them in the direction of all picking
> the same one.

History says that back-ends are updated more slowly than front-ends.  For
example, my fixes to QEMU's serial port emulation that have been in Xen's
mainline for ~2 years are still not widely deployed on EC2.  Folks running
FreeBSD there are using an ugly hack to FreeBSD's serial driver so they
can get console output.

So, if you want your front-ends to have optimal performance regardless of
what cloud or appliance they are running on, the two types will have to be
supported for some time.  Neither is better than the other, just different.

The opposite is true for back-ends.  If your customer controls the guest
environment and chooses not upgrade, you can't kill support for the
variant they use.

> I think the decision should made by the current state of mainline Linux
> & BSD front and backends, i.e. we should prefer what has been upstreamed
> rather than private forks if possible. Does anyone know what that state
> is?

The state is a bit embarrassing on the BSD side.  FreeBSD has had a
multi-page ring extension since October of 2010.  Unfortunately, I wrote
this extension before stumbling upon the Citrix blkif patch or the
extension being used on EC2.  It is closest to the EC2 implementation,
but not quite compatible.  The saving grace is that I don't know of any
deployments of this back-end outside of Spectra, and we have not shipped
it to customers, so I plan to upstream block front and back drivers that
only implement the Citrix and EC2 style extension once blkif.h settles.  A
preliminary version of these changes went out for review a couple weeks
ago.

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