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

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

On 06/28/2013 04:14 PM, Eric Blake wrote:
> On 06/28/2013 01:59 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
> s/enable/enabled/
>
>> at compile-time.
>>
>> Signed-off-by: Michael R. Hines <mrhines@us.ibm.com>
>> ---
>>   docs/rdma.txt |   51 ++++++++++++++++++++++++++++++---------------------
>>   1 file changed, 30 insertions(+), 21 deletions(-)
>>
>> diff --git a/docs/rdma.txt b/docs/rdma.txt
>> index 45a4b1d..f3083fd 100644
>> --- a/docs/rdma.txt
>> +++ b/docs/rdma.txt
>> @@ -35,7 +35,7 @@ memory tracked during each live migration iteration round cannot keep pace
>>   with the rate of dirty memory produced by the workload.
>>   
>>   RDMA currently comes in two flavors: both Ethernet based (RoCE, or RDMA
>> -over Convered Ethernet) as well as Infiniband-based. This implementation of
>> +over Converged Ethernet) as well as Infiniband-based. This implementation of
>>   migration using RDMA is capable of using both technologies because of
>>   the use of the OpenFabrics OFED software stack that abstracts out the
>>   programming model irrespective of the underlying hardware.
>> @@ -188,9 +188,9 @@ header portion and a data portion (but together are transmitted
>>   as a single SEND message).
>>   
>>   Header:
>> -    * Length  (of the data portion, uint32, network byte order)
>> -    * Type    (what command to perform, uint32, network byte order)
>> -    * Repeat  (Number of commands in data portion, same type only)
>> +    * Length               (of the data portion, uint32, network byte order)
>> +    * Type                 (what command to perform, uint32, network byte order)
>> +    * Repeat               (Number of commands in data portion, same type only)
> Perhaps worth splitting into two patches, trivial typo/format fixes vs.
> new content?  But I won't insist, as anyone backporting rdma to an older
> branch will pick up all related rdma patches, rather than stopping at
> just the initial implementation.

I don't mind resending - it's a quick "git am" followed by "git commit 
--amend".

>> +     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)
> Alignment looks off :)

> At any rate, touching that up is trivial enough that I don't mind if you
> add: Reviewed-by: Eric Blake <eblake@redhat.com>
>
Thanks, Eric.