From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39012) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Usf7D-00071T-JP for qemu-devel@nongnu.org; Fri, 28 Jun 2013 16:17:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Usf7A-0007LZ-OZ for qemu-devel@nongnu.org; Fri, 28 Jun 2013 16:17:55 -0400 Received: from e39.co.us.ibm.com ([32.97.110.160]:55158) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Usf7A-0007LQ-Hi for qemu-devel@nongnu.org; Fri, 28 Jun 2013 16:17:52 -0400 Received: from /spool/local by e39.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 28 Jun 2013 14:17:51 -0600 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id DB2C73E40044 for ; Fri, 28 Jun 2013 14:17:28 -0600 (MDT) Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r5SKHm6e380348 for ; Fri, 28 Jun 2013 14:17:48 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r5SKHmTR020316 for ; Fri, 28 Jun 2013 14:17:48 -0600 Message-ID: <51CDEF6A.4050606@linux.vnet.ibm.com> Date: Fri, 28 Jun 2013 16:17:46 -0400 From: "Michael R. Hines" MIME-Version: 1.0 References: <1372449603-20431-1-git-send-email-mrhines@linux.vnet.ibm.com> <1372449603-20431-2-git-send-email-mrhines@linux.vnet.ibm.com> <51CDEEA7.4030703@redhat.com> In-Reply-To: <51CDEEA7.4030703@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 1/8] rdma: update documentation to reflect new unpin support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: aliguori@us.ibm.com, quintela@redhat.com, qemu-devel@nongnu.org, owasserm@redhat.com, abali@us.ibm.com, mrhines@us.ibm.com, gokul@us.ibm.com, pbonzini@redhat.com, chegu_vinod@hp.com, knoel@redhat.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" >> >> 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 >> --- >> 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 > Thanks, Eric.