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

["Michael R. Hines" <mrhines@linux.vnet.ibm.com>]

On 06/27/2013 07:09 PM, Eric Blake wrote:
> On 06/27/2013 04:44 PM, mrhines@linux.vnet.ibm.com wrote:
>> From: "Michael R. Hines" <mrhines@us.ibm.com>
>>
>> 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 <mrhines@us.ibm.com>
>> ---
>>   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.)