[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 1/6] rdma: update documentation to reflect new u
From: |
Eric Blake |
Subject: |
Re: [Qemu-devel] [PATCH 1/6] rdma: update documentation to reflect new unpin support |
Date: |
Thu, 27 Jun 2013 17:09:14 -0600 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 |
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