Re: [Qemu-devel] [PATCH 1/6] rdma: update documentation to reflect new unpin support

[Eric Blake]

On 06/27/2013 04:44 PM, address@hidden wrote:
> From: "Michael R. Hines" <address@hidden>
> 
> As requested, the protocol now includes memory unpinning support.
> This has been implemented in a non-optimized manner, in such a way
> that one could devise an LRU or other workload-specific information
> on top of the basic mechanism to influence the way unpinning happens
> during runtime.
> 
> The feature is not yet user-facing, and is thus can only be enable
> at compile-time.
> 
> Signed-off-by: Michael R. Hines <address@hidden>
> ---
>  docs/rdma.txt |   23 ++++++++++++++---------
>  1 file changed, 14 insertions(+), 9 deletions(-)
> 

> +++ b/docs/rdma.txt
> @@ -204,15 +204,17 @@ observations on the maximum future benefit of 
> simultaneous page registrations.
>  
>  The 'type' field has 10 different command values:

10 != ...

>      1. Unused
> -    2. Error              (sent to the source during bad things)
> -    3. Ready              (control-channel is available)
> -    4. QEMU File          (for sending non-live device state)
> -    5. RAM Blocks request (used right after connection setup)
> -    6. RAM Blocks result  (used right after connection setup)
> -    7. Compress page      (zap zero page and skip registration)
> -    8. Register request   (dynamic chunk registration)
> -    9. Register result    ('rkey' to be used by sender)
> -    10. Register finished  (registration for current iteration finished)
> +    2. Error                (sent to the source during bad things)
> +    3. Ready                (control-channel is available)
> +    4. QEMU File            (for sending non-live device state)
> +    5. RAM Blocks request   (used right after connection setup)
> +    6. RAM Blocks result    (used right after connection setup)
> +    7. Compress page        (zap zero page and skip registration)
> +    8. Register request     (dynamic chunk registration)
> +    9. Register result      ('rkey' to be used by sender)
> +    10. Register finished   (registration for current iteration finished)
> +    11. Unregister request  (unpin previously registered memory)
> +    12. Unregister finished (confirmation that unpin completed)

...12.

Also, is it worth indenting things with extra spaces in your original
series, so that this series (and even future follow-on series) have more
space to use without having to reindent?  That is, why not leave room
after your current longest command:

    12. Unregister finished     (confirmation that unpin completed)

and adjust the remaining lines to line up.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature