[1/6] rdma: update documentation to reflect new unpin support

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(-)

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.

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.)