From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43509) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UU0ML-0006To-Mo for qemu-devel@nongnu.org; Sun, 21 Apr 2013 15:55:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UU0MJ-0007U6-2B for qemu-devel@nongnu.org; Sun, 21 Apr 2013 15:55:37 -0400 Received: from e9.ny.us.ibm.com ([32.97.182.139]:52282) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UU0MI-0007Tv-U0 for qemu-devel@nongnu.org; Sun, 21 Apr 2013 15:55:34 -0400 Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Sun, 21 Apr 2013 15:55:34 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id C18B038C801A for ; Sun, 21 Apr 2013 15:55:31 -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 r3LJtV94304516 for ; Sun, 21 Apr 2013 15:55:31 -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 r3LJtVfH027647 for ; Sun, 21 Apr 2013 15:55:31 -0400 Message-ID: <51744433.3010304@linux.vnet.ibm.com> Date: Sun, 21 Apr 2013 15:55:31 -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> <51740E34.6040403@linux.vnet.ibm.com> <20130421185942.GA17565@redhat.com> In-Reply-To: <20130421185942.GA17565@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: "Michael S. Tsirkin" 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, Paolo Bonzini On 04/21/2013 02:59 PM, Michael S. Tsirkin wrote: > On Sun, Apr 21, 2013 at 12:05:08PM -0400, Michael R. Hines wrote: >> 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 > My interest was in the protocol used, so as long as you don't > intend to enhance the protocol any further, please drop me from the > Cc list on future version of these patches. > > I don't take any position on whether your patches should be merged > in their current form. > Acknowledged.