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 13, 2012, at 5:35 AM, Ian Campbell wrote:

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

Anyone care to flip a coin?

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