On 06/28/2013 01:59 PM, mrhi...@linux.vnet.ibm.com wrote: > From: "Michael R. Hines" <mrhi...@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 <mrhi...@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.
> + 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 <ebl...@redhat.com>
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
