Re: [Xen-devel] [PATCH v2] docs: expand persistent grants protocol

[Mats Petersson <mats.petersson@xxxxxxxxxx>]

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@xxxxxxxxxx>
> 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@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

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