From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38169) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Usf48-0005VR-QI for qemu-devel@nongnu.org; Fri, 28 Jun 2013 16:14:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Usf46-0005w3-5Y for qemu-devel@nongnu.org; Fri, 28 Jun 2013 16:14:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:28491) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Usf45-0005vy-Kv for qemu-devel@nongnu.org; Fri, 28 Jun 2013 16:14:41 -0400 Message-ID: <51CDEEA7.4030703@redhat.com> Date: Fri, 28 Jun 2013 14:14:31 -0600 From: Eric Blake 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> In-Reply-To: <1372449603-20431-2-git-send-email-mrhines@linux.vnet.ibm.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----enig2RJNURDWQEMFXWSWGLFLP" 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: 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) ------enig2RJNURDWQEMFXWSWGLFLP Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 06/28/2013 01:59 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 s/enable/enabled/ > at compile-time. >=20 > Signed-off-by: Michael R. Hines > --- > docs/rdma.txt | 51 ++++++++++++++++++++++++++++++-------------------= -- > 1 file changed, 30 insertions(+), 21 deletions(-) >=20 > 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 r= ound cannot keep pace > with the rate of dirty memory produced by the workload. > =20 > RDMA currently comes in two flavors: both Ethernet based (RoCE, or RDM= A > -over Convered Ethernet) as well as Infiniband-based. This implementati= on of > +over Converged Ethernet) as well as Infiniband-based. This implementat= ion 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). > =20 > 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 b= yte order) > + * Repeat (Number of commands in data portion, same t= ype 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 --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org ------enig2RJNURDWQEMFXWSWGLFLP 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/ iQEcBAEBCAAGBQJRze6nAAoJEKeha0olJ0NqJ+oH/AlHtxD1zSyYRMBTyeeFutXq BNRDCtLfLf0rnRqjKDADDN2kV4YmmqzH9eRZsLu/OID+9kM9rRXTyO8YhjQwYfuF hKfSzYKgeH9YbfT0E6PUix/Gb2SCZVXyj3B8RE0qNix06OE6ShztQCCMVQbX5Mcf dlrAyHsm9JR2uorRPp4JaJEJC2y5WGTcBBClYlezYnIVOtSQkPFvWj8aF8k+dc/0 a3yTOTHZfXHHrl5Pld3gVO5MOueF8UGmypvLA+WAVJ9TnU4eD4PDKEZGjGFFa547 48JBjRrn+/GtgTN5kr8v4+EtcKAAniiJHpxi6ZGpCY/VX9QvQZiZCZP7INky8Kk= =eKlF -----END PGP SIGNATURE----- ------enig2RJNURDWQEMFXWSWGLFLP--