All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Roger Pau Monne <roger.pau@citrix.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [PATCH] docs: document persistent grants
Date: Tue, 30 Oct 2012 17:08:55 -0400	[thread overview]
Message-ID: <20121030210854.GD21481@phenom.dumpdata.com> (raw)
In-Reply-To: <1351508996-54975-1-git-send-email-roger.pau@citrix.com>

On Mon, Oct 29, 2012 at 12:09:56PM +0100, Roger Pau Monne wrote:
> Document the new persistent grants block-device feature.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
> ---
>  xen/include/public/io/blkif.h |   29 +++++++++++++++++++++++++++++
>  1 files changed, 29 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/include/public/io/blkif.h b/xen/include/public/io/blkif.h
> index d71c7f1..accdda4 100644
> --- a/xen/include/public/io/blkif.h
> +++ b/xen/include/public/io/blkif.h
> @@ -126,6 +126,19 @@
>   *      of this type may still be returned at any time with the
>   *      BLKIF_RSP_EOPNOTSUPP result code.
>   *
> + * feature-persistent
> + *      Values:         0/1 (boolean)

That is not a boolean strickly. That would be 'true/false'. Perhaps 'int'?

> + *      Default Value:  0
> + *      Notes: 7
> + *
> + *      A value of "1" indicates that the backend can keep the grants used
> + *      by the frontend driver mapped, so the same set of grants should be
> + *      used in all transactions. The maximum number of grants the backend
> + *      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.
> + *
>   *----------------------- Request Transport Parameters ------------------------
>   *
>   * max-ring-page-order
> @@ -242,6 +255,15 @@
>   *      The size of the frontend allocated request ring buffer in units of
>   *      machine pages.  The value must be a power of 2.
>   *
> + * feature-persistent
> + *      Values:         0/1 (boolean)
> + *      Default Value:  0
> + *      Notes: 7, 8
> + *
> + *      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).
> + *
>   *------------------------- Virtual Device Properties -------------------------
>   *
>   * device-type
> @@ -279,6 +301,13 @@
>   *     'ring-ref' is used to communicate the grant reference for this
>   *     page to the backend.  When using a multi-page ring, the 'ring-ref'
>   *     node is not created.  Instead 'ring-ref0' - 'ring-refN' are used.
> + * (7) When using persistent grants data has to be copied from/to the page
> + *     where the grant is currently mapped. The overhead of doing this copy
> + *     however doesn't suppress the speed improvement of not having to unmap
> + *     the grants.
> + * (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 this grants and require write permisions.
>   */
>  
>  /*
> -- 
> 1.7.7.5 (Apple Git-26)
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

  parent reply	other threads:[~2012-10-30 21:08 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-29 11:09 [PATCH] docs: document persistent grants Roger Pau Monne
2012-10-30 14:53 ` Ian Jackson
2012-10-30 21:08 ` Konrad Rzeszutek Wilk [this message]
2012-11-09 15:07 ` Ian Campbell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20121030210854.GD21481@phenom.dumpdata.com \
    --to=konrad@kernel.org \
    --cc=roger.pau@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.