On 06/28/2013 04:14 PM, Eric Blake wrote:
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.
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 <ebl...@redhat.com>
Thanks, Eric.