From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:58651) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UI1TA-0004vc-Cs for qemu-devel@nongnu.org; Tue, 19 Mar 2013 14:41:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UI1T6-0004a7-8F for qemu-devel@nongnu.org; Tue, 19 Mar 2013 14:41:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54058) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UI1T6-0004Zr-1D for qemu-devel@nongnu.org; Tue, 19 Mar 2013 14:41:04 -0400 Message-ID: <5148B137.4070300@redhat.com> Date: Tue, 19 Mar 2013 19:40:55 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1363576743-6146-1-git-send-email-mrhines@linux.vnet.ibm.com> <1363576743-6146-9-git-send-email-mrhines@linux.vnet.ibm.com> <5146D9BF.3030407@redhat.com> <51477A26.8090600@linux.vnet.ibm.com> <51482D78.3010301@redhat.com> <5148643F.2070401@linux.vnet.ibm.com> <51486733.7060207@redhat.com> <51486AD0.80309@linux.vnet.ibm.com> <51486C0D.2040609@redhat.com> <514871C2.5020108@linux.vnet.ibm.com> <5148748C.5050509@redhat.com> <5148AE2F.2030206@linux.vnet.ibm.com> In-Reply-To: <5148AE2F.2030206@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH RDMA support v4: 08/10] introduce QEMUFileRDMA List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael R. Hines" Cc: aliguori@us.ibm.com, mst@redhat.com, qemu-devel@nongnu.org, owasserm@redhat.com, abali@us.ibm.com, mrhines@us.ibm.com, gokul@us.ibm.com Il 19/03/2013 19:27, Michael R. Hines ha scritto: >>> >> That however gives me an idea... Instead of the full drain at the end >> of an iteration, does it make sense to do a "partial" drain at every >> chunk full, so that you don't have > N bytes pending and the downtime is >> correspondingly limited? > > > Sure, you could do that, but it seems overly complex just to avoid > a single flush() call at the end of each iteration, right? Would it really be that complex? Not having an extra QEMUFile op perhaps balances that complexity (and the complexity remains hidden in rdma.c, which is an advantage). You could alternatively drain every N megabytes sent, or something like that. But a partial drain would help obeying the maximum downtime limitations. Paolo