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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2012-02-09 at 15:12 +0000, Justin T. Gibbs wrote:
> 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 agree with all you say, the practicalities certainly mean we may well
be stuck with both forever. I don't think there is any harm in
documenting one of them as preferred though.

If someone has the freedom (or desire) to only implement one of the two
in their code base then that provides guidance as to which it should be,
at least then we will be encouraging the right trajectory. Also it gives
some small amount of ammunition to people who are stuck with a provider
(of either front or backend) of the wrong type for their environment and
helps break the stalemate as to who should fix their end (however
helpful that might be in practice).

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

Cool, thanks.

Ian.


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