From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38103) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1USwzK-0003KI-VT for qemu-devel@nongnu.org; Thu, 18 Apr 2013 18:07:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1USwzJ-0003x0-SA for qemu-devel@nongnu.org; Thu, 18 Apr 2013 18:07:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:30232) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1USwzJ-0003wv-K0 for qemu-devel@nongnu.org; Thu, 18 Apr 2013 18:07:29 -0400 Message-ID: <51706E9C.9@redhat.com> Date: Thu, 18 Apr 2013 16:07:24 -0600 From: Eric Blake MIME-Version: 1.0 References: <1366240040-10730-1-git-send-email-mrhines@linux.vnet.ibm.com> <1366240040-10730-8-git-send-email-mrhines@linux.vnet.ibm.com> In-Reply-To: <1366240040-10730-8-git-send-email-mrhines@linux.vnet.ibm.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----enig2FFRIRGPAPWAUQLPJKFUK" Subject: Re: [Qemu-devel] [PULL v4 07/11] rdma: introduce capability for chunk registration 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, mst@redhat.com, qemu-devel@nongnu.org, owasserm@redhat.com, abali@us.ibm.com, mrhines@us.ibm.com, gokul@us.ibm.com, pbonzini@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2FFRIRGPAPWAUQLPJKFUK Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/17/2013 05:07 PM, mrhines@linux.vnet.ibm.com wrote: > From: "Michael R. Hines" >=20 > This capability allows you to disable dynamic chunk registration > for better throughput on high-performance links. >=20 > It is enabled by default. >=20 > Signed-off-by: Michael R. Hines > --- > migration.c | 10 ++++++++++ > qapi-schema.json | 8 +++++++- > 2 files changed, 17 insertions(+), 1 deletion(-) > # > +# @x-chunk-register-destination: (since 1.5) RDMA option which control= s whether > +# or not the entire VM memory footprint is mlock() on demand = or all at once. > +# Refer to docs/rdma.txt for more advice on when to take adva= ntage option. s/take advantage/use this/ > +# Enabled by default, and will be renamed to 'chunk-register-= destination'=20 > +# after experimental testing is complete. I wouldn't promise a rename - after all, testing may prove that we can settle on enough heuristics to set this appropriately without needing a user option, even for the workloads where it makes a difference. Thus, I think better wording might be: Enabled by default. Experimental: may be renamed or removed after further testing is complete. Sorry for not thinking about this earlier, but typically you want a capability bit to default to 0 - it's much easier to assume that a bit not present behaves the same as a bit that is present and 0. Or put another way, a older management app that asks for all enabled capabilities on a newer qemu has an easier time ignoring 0 bits that it doesn't recognize (oh, some new feature I don't know about, but it isn't on, so it can't hurt) than it does ignoring 1 bits (oh, a feature I don't recognize, but it's enabled - will it mess up my migration?). Since this is a bool, I would much rather can we rename the capability to express the opposite sense, and default it to 0. I'm not even sure from your description here whether 'true' means 'mlock() on demand' or 'all at once', just that I'm supposed to read rdma.txt to decide if I want to move away from the default. /me reads patch 11 again... and wonders why the docs came last instead of first in the series... I guess the opposite sense could be named 'x-rdma-pin-all'; default false means to do chunk registration and release, true means to pin all memory up front. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org ------enig2FFRIRGPAPWAUQLPJKFUK 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/ iQEcBAEBCAAGBQJRcG6cAAoJEKeha0olJ0Nq5YIH/i6o7vWfpwLPT/nfQOwuKOeT +CgckSnH42fF5lSKhQ5aiuyCmvoLLb8zJ2L5yCh3f6ruFM4/Ip8a+qyrwg5lajYh o8Ri/nsqcqTk9ZuSJbkT3F5AhdWGu573DES7ux8xKM63ujXp1GeXe1zNhCCrplNq txf6hxf4+XFZ4lRpp2juqPBg/JDq0Ke+fC7cJuWPCLAjH13H5fcZAJHOsJSCrW0F wEHitJahPWCcbBHkT0HaebcV4WK+451nA/HyPT7W4eLXgwVg/+ksj+rjIvRnoX5A 0Xg2G1dTpeqL7elsGZ2nqqP6+Q+lbgJNtN0/y+v1um4t5vvjZ2G1fjGuxLfuDyE= =i/2+ -----END PGP SIGNATURE----- ------enig2FFRIRGPAPWAUQLPJKFUK--