From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50642) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UsLJa-0001AJ-14 for qemu-devel@nongnu.org; Thu, 27 Jun 2013 19:09:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UsLJY-0004D0-TF for qemu-devel@nongnu.org; Thu, 27 Jun 2013 19:09:21 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49725) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UsLJY-0004Cs-LU for qemu-devel@nongnu.org; Thu, 27 Jun 2013 19:09:20 -0400 Message-ID: <51CCC61A.3000607@redhat.com> Date: Thu, 27 Jun 2013 17:09:14 -0600 From: Eric Blake 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> In-Reply-To: <1372373098-5877-2-git-send-email-mrhines@linux.vnet.ibm.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----enig2ETKKTVVFHSDMLQBSWBBX" 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: mrhines@linux.vnet.ibm.com 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 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2ETKKTVVFHSDMLQBSWBBX Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 06/27/2013 04:44 PM, mrhines@linux.vnet.ibm.com wrote: > From: "Michael R. Hines" >=20 > 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. >=20 > The feature is not yet user-facing, and is thus can only be enable > at compile-time. >=20 > Signed-off-by: Michael R. Hines > --- > docs/rdma.txt | 23 ++++++++++++++--------- > 1 file changed, 14 insertions(+), 9 deletions(-) >=20 > +++ b/docs/rdma.txt > @@ -204,15 +204,17 @@ observations on the maximum future benefit of sim= ultaneous page registrations. > =20 > The 'type' field has 10 different command values: 10 !=3D ... > 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 finishe= d) > + 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 finish= ed) > + 11. Unregister request (unpin previously registered memory) > + 12. Unregister finished (confirmation that unpin completed) =2E..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. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org ------enig2ETKKTVVFHSDMLQBSWBBX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJRzMYaAAoJEKeha0olJ0NqFJEH/A2T7hp0W0bboA5cQq/EcIal fPRH/IpxUJmDlMcPp0a3qkczHuBxYkNAhkFVPpnAg7yzzWAoQyIktTrDOTd7G0o9 aikh5GHhkJR6B/ZxrdDkVhAlhzvQpR26m/V3NGABPY7n7Fu8QExXOSJxd9RACxg4 RD+RdD0UMASdvtz3N9OPXHv9Nn4SrHLZaTDppjOa2vNPpW593+u0YWqnu7/HZVcN MrioG62FOsaqA+8Ag6k7X79Mc4cI1FPEuqYau0/EJm83Ei7Yz1br6d/DuVIRTc9d RdFd0Ja91D0XjNs9fFRgO2ujMEYzeaASXzqURO68bT87ntTtqC9f0O8PTb1iGC4= =KPhb -----END PGP SIGNATURE----- ------enig2ETKKTVVFHSDMLQBSWBBX--