qemu-devel
[Top][All Lists]
Advanced

[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: Michael R. Hines
Subject: Re: [Qemu-devel] [PATCH 1/6] rdma: update documentation to reflect new unpin support
Date: Fri, 28 Jun 2013 09:17:11 -0400
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5

On 06/27/2013 07:09 PM, Eric Blake wrote:
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.

Understood. (I got your other corrections in as well - just sent this
series out too fast before I read your other emails.)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]