From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:39224) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTwlQ-0004gE-D0 for qemu-devel@nongnu.org; Sun, 21 Apr 2013 12:05:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UTwlN-0001mp-QD for qemu-devel@nongnu.org; Sun, 21 Apr 2013 12:05:16 -0400 Received: from e7.ny.us.ibm.com ([32.97.182.137]:33683) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTwlN-0001mc-Mx for qemu-devel@nongnu.org; Sun, 21 Apr 2013 12:05:13 -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 ; Sun, 21 Apr 2013 12:05:12 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id A67E46E8040 for ; Sun, 21 Apr 2013 12:05:06 -0400 (EDT) Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r3LG59HO211138 for ; Sun, 21 Apr 2013 12:05:09 -0400 Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r3LG59Pb012729 for ; Sun, 21 Apr 2013 12:05:09 -0400 Message-ID: <51740E34.6040403@linux.vnet.ibm.com> Date: Sun, 21 Apr 2013 12:05:08 -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> <20130420170240.GA16115@redhat.com> <5173E759.5080906@redhat.com> In-Reply-To: <5173E759.5080906@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; 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: Paolo Bonzini Cc: aliguori@us.ibm.com, quintela@redhat.com, "Michael S. Tsirkin" , qemu-devel@nongnu.org, owasserm@redhat.com, abali@us.ibm.com, mrhines@us.ibm.com, gokul@us.ibm.com On 04/21/2013 09:19 AM, Paolo Bonzini wrote: > Il 20/04/2013 19:02, Michael S. Tsirkin ha scritto: >>>> I guess the opposite sense could be named 'x-rdma-pin-all'; default >>>> false means to do chunk registration and release, >> chunk release only happens after migration is complete unfortunately. >> This means that eventually all initialized memory is pinned, regardless >> of the setting (this is fixable but there's no plan to fix this, at this >> point). So pin-all might be misleading to some. >> >> I agree 'chunk' is unnecessarily low level though. >> The only difference ATM is pinning of uninitialized memory so I think a >> better name would be 'x-rdma-pin-uninitialized' or some such. >> > x-rdma-pin-all is a better choice. x-rdma-pin-uninitialized is also too > low level. > > Since this series is likely to miss 1.5 at this point, we could > implement the unregistration part of the protocol in the destination. > This way, any heuristic we add to the source will not break backwards > compatibility. > > Paolo > The release cycles are relatively fast, according to the website, so I don't have any problem with missing 1.5 to make sure that everybody is happy and have had a chance to test the software. But: Let me repeat: we have already discussed in previous emails that ibv_reg_mr() => error + notify source + aborted migration would be an adequate solution for merging. Also: let me repeat: We have no intention nor plans (at least not from IBM research) to promise to develop nor even explore the effects of unregistration in the RDMA protocol as we have zero data to show that it does not adversely affect the performance of the solution. Unless someone puts in the man-hours to show hard data (even with micro-benchmark) that migration throughput and migration latency performance and migration convergence are not unaffected by such a change in the protocol, then such a change would have to be implemented as a patch by another member of the community and an option be clearly made in the QEMU monitor so that it could be disabled if the user chose to do so. - Michael