Re: [PATCH v2] docs: expand persistent grants protocol

[Mats Petersson <mats.petersson@citrix.com>]

On 04/12/12 15:51, Ian Campbell wrote:
> On Thu, 2012-11-29 at 15:15 +0000, Roger Pau Monne wrote:
>> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> Acked + applied, thanks.
>
>> ---
>>   xen/include/public/io/blkif.h |   37 ++++++++++++++++++++++++++++++++++---
>>   1 files changed, 34 insertions(+), 3 deletions(-)
>>
>> diff --git a/xen/include/public/io/blkif.h b/xen/include/public/io/blkif.h
>> index 8df5866..1f0fbd6 100644
>> --- a/xen/include/public/io/blkif.h
>> +++ b/xen/include/public/io/blkif.h
>> @@ -137,7 +137,22 @@
>>    *      can map persistently depends on the implementation, but ideally it
>>    *      should be RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST. Using this
>>    *      feature the backend doesn't need to unmap each grant, preventing
>> - *      costly TLB flushes.
>> + *      costly TLB flushes. The backend driver should only map grants
>> + *      persistently if the frontend supports it. If a backend driver chooses
>> + *      to use the persistent protocol when the frontend doesn't support it,
>> + *      it will probably hit the maximum number of persistently mapped grants
>> + *      (due to the fact that the frontend won't be reusing the same grants),
>> + *      and fall back to non-persistent mode. Backend implementations may
>> + *      shrink or expand the number of persistently mapped grants without
>> + *      notifying the frontend depending on memory constraints (this might
>> + *      cause a performance degradation).
>> + *
>> + *      If a backend driver wants to limit the maximum number of persistently
>> + *      mapped grants to a value less than RING_SIZE *
>> + *      BLKIF_MAX_SEGMENTS_PER_REQUEST a LRU strategy should be used to
>> + *      discard the grants that are less commonly used. Using a LRU in the
>> + *      backend driver paired with a LIFO queue in the frontend will
>> + *      allow us to have better performance in this scenario.
>>    *
>>    *----------------------- Request Transport Parameters ------------------------
>>    *
>> @@ -258,11 +273,23 @@
>>    * feature-persistent
>>    *      Values:         0/1 (boolean)
>>    *      Default Value:  0
>> - *      Notes: 7, 8
>> + *      Notes: 7, 8, 9
>>    *
>>    *      A value of "1" indicates that the frontend will reuse the same grants
>>    *      for all transactions, allowing the backend to map them with write
>> - *      access (even when it should be read-only).
>> + *      access (even when it should be read-only). If the frontend hits the
>> + *      maximum number of allowed persistently mapped grants, it can fallback
>> + *      to non persistent mode. This will cause a performance degradation,
>> + *      since the the backend driver will still try to map those grants
>> + *      persistently. Since the persistent grants protocol is compatible with
>> + *      the previous protocol, a frontend driver can choose to work in
>> + *      persistent mode even when the backend doesn't support it.
>> + *
>> + *      It is recommended that the frontend driver stores the persistently
>> + *      mapped grants in a LIFO queue, so a subset of all persistently mapped
>> + *      grants gets used commonly. This is done in case the backend driver
>> + *      decides to limit the maximum number of persistently mapped grants
>> + *      to a value less than RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST.
>>    *
>>    *------------------------- Virtual Device Properties -------------------------
>>    *
>> @@ -308,6 +335,10 @@
>>    * (8) The frontend driver has to allow the backend driver to map all grants
>>    *     with write access, even when they should be mapped read-only, since
>>    *     further requests may reuse these grants and require write permissions.
>> + * (9) Linux implementation doesn't have a limit on the maximum number of
>> + *     grants that can be persistently mapped in the frontend driver, but
>> + *     due to the frontent driver implementation it should never be bigger
frontent -> frontend?

--
Mats
>> + *     than RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST.
>>    */
>>   
>>   /*
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel