From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41870) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fYBC2-0004P9-LY for qemu-devel@nongnu.org; Wed, 27 Jun 2018 10:13:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fYBBz-0006fS-Ds for qemu-devel@nongnu.org; Wed, 27 Jun 2018 10:13:10 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:37396 helo=mx1.redhat.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fYBBz-0006eg-95 for qemu-devel@nongnu.org; Wed, 27 Jun 2018 10:13:07 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E712940C6296 for ; Wed, 27 Jun 2018 14:13:06 +0000 (UTC) Date: Wed, 27 Jun 2018 15:13:04 +0100 From: "Dr. David Alan Gilbert" Message-ID: <20180627141303.GH2423@work-vm> References: <20180627105112.31401-1-peterx@redhat.com> <20180627105112.31401-4-peterx@redhat.com> <20180627122544.GG2423@work-vm> <20180627130319.GF2516@xz-mi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180627130319.GF2516@xz-mi> Subject: Re: [Qemu-devel] [PATCH v2 3/5] migration: do explicit incoming setup for rdma List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Xu Cc: qemu-devel@nongnu.org, Juan Quintela * Peter Xu (peterx@redhat.com) wrote: > On Wed, Jun 27, 2018 at 01:25:45PM +0100, Dr. David Alan Gilbert wrote: > > * Peter Xu (peterx@redhat.com) wrote: > > > RDMA does not support postcopy recovery, so no need to go into such > > > logic. Instead of calling migration_fd_process_incoming(), let's call > > > the two functions that setup the incoming migration. There should have > > > no functional change at all. > > > > Can you explain why we need to though? The reason I ask is that there > > is Lidong Chen's work that gets postcopy partially working with RDMA, so > > then the next question is bound to be recovery. > > Ah if so this patch needs to change. Could you paste me the message > id of the work? Or link? > > After all I'll need to keep this bit, but I am just curious about what > is "partially" mean here. :) https://patchwork.ozlabs.org/cover/925525/ It enables postcopy with RDMA, but once it switches into postcopy mode it doesn't use the fast features of RDMA, it still shuffles the data as a stream (using some more basic RDMA features). Dave > Thanks, > > -- > Peter Xu -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK