From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38426) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1USzI2-0007Ik-Ml for qemu-devel@nongnu.org; Thu, 18 Apr 2013 20:35:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1USzHz-0007jv-Fa for qemu-devel@nongnu.org; Thu, 18 Apr 2013 20:34:57 -0400 Received: from e39.co.us.ibm.com ([32.97.110.160]:52558) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1USzHz-0007jk-8p for qemu-devel@nongnu.org; Thu, 18 Apr 2013 20:34:55 -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 ; Thu, 18 Apr 2013 18:34:54 -0600 Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id 3F3C61FF0026 for ; Thu, 18 Apr 2013 18:29:49 -0600 (MDT) Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r3J0Ynap133238 for ; Thu, 18 Apr 2013 18:34:49 -0600 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r3J0bd9b004919 for ; Thu, 18 Apr 2013 18:37:39 -0600 Message-ID: <51709127.9000205@linux.vnet.ibm.com> Date: Thu, 18 Apr 2013 20:34:47 -0400 From: "Michael R. Hines" 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> <51706E9C.9@redhat.com> In-Reply-To: <51706E9C.9@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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: Eric Blake Cc: aliguori@us.ibm.com, mst@redhat.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 On 04/18/2013 06:07 PM, Eric Blake wrote: > On 04/17/2013 05:07 PM, mrhines@linux.vnet.ibm.com wrote: >> From: "Michael R. Hines" >> >> This capability allows you to disable dynamic chunk registration >> for better throughput on high-performance links. >> >> It is enabled by default. >> >> 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 controls 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 advantage option. > s/take advantage/use this/ > >> +# Enabled by default, and will be renamed to 'chunk-register-destination' >> +# 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. Acknowledged. > 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'll move patch 11 to the top next time. No problem. > 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. > Yes, I would be happy to rename the capability and default to false. Is everybody else comfortable with that? - Michael