* [PATCH v2] docs: expand persistent grants protocol
@ 2012-11-29 15:15 Roger Pau Monne
2012-12-04 15:51 ` Ian Campbell
0 siblings, 1 reply; 3+ messages in thread
From: Roger Pau Monne @ 2012-11-29 15:15 UTC (permalink / raw)
To: xen-devel; +Cc: Roger Pau Monne
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
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
+ * than RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST.
*/
/*
--
1.7.7.5 (Apple Git-26)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH v2] docs: expand persistent grants protocol
2012-11-29 15:15 [PATCH v2] docs: expand persistent grants protocol Roger Pau Monne
@ 2012-12-04 15:51 ` Ian Campbell
2012-12-04 15:58 ` Mats Petersson
0 siblings, 1 reply; 3+ messages in thread
From: Ian Campbell @ 2012-12-04 15:51 UTC (permalink / raw)
To: Roger Pau Monne; +Cc: xen-devel@lists.xen.org
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
> + * than RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST.
> */
>
> /*
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH v2] docs: expand persistent grants protocol
2012-12-04 15:51 ` Ian Campbell
@ 2012-12-04 15:58 ` Mats Petersson
0 siblings, 0 replies; 3+ messages in thread
From: Mats Petersson @ 2012-12-04 15:58 UTC (permalink / raw)
To: xen-devel
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2012-12-04 15:58 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-11-29 15:15 [PATCH v2] docs: expand persistent grants protocol Roger Pau Monne
2012-12-04 15:51 ` Ian Campbell
2012-12-04 15:58 ` Mats Petersson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).