From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47798) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UsYYF-0001x5-M8 for qemu-devel@nongnu.org; Fri, 28 Jun 2013 09:17:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UsYYA-00044I-P5 for qemu-devel@nongnu.org; Fri, 28 Jun 2013 09:17:23 -0400 Received: from e7.ny.us.ibm.com ([32.97.182.137]:34173) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UsYYA-000448-Kx for qemu-devel@nongnu.org; Fri, 28 Jun 2013 09:17:18 -0400 Received: from /spool/local by e7.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 28 Jun 2013 09:17:18 -0400 Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id C9F3838C8045 for ; Fri, 28 Jun 2013 09:17:14 -0400 (EDT) Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r5SDHFBK65601694 for ; Fri, 28 Jun 2013 09:17:15 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r5SDHE0P008875 for ; Fri, 28 Jun 2013 10:17:14 -0300 Message-ID: <51CD8CD7.6020407@linux.vnet.ibm.com> Date: Fri, 28 Jun 2013 09:17:11 -0400 From: "Michael R. Hines" MIME-Version: 1.0 References: <1372373098-5877-1-git-send-email-mrhines@linux.vnet.ibm.com> <1372373098-5877-2-git-send-email-mrhines@linux.vnet.ibm.com> <51CCC61A.3000607@redhat.com> In-Reply-To: <51CCC61A.3000607@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/6] 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/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" >> >> 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 >> --- >> 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.)