From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46834) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQxRB-0002wm-QU for qemu-devel@nongnu.org; Wed, 03 Feb 2016 08:25:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aQxR8-00085X-2T for qemu-devel@nongnu.org; Wed, 03 Feb 2016 08:25:37 -0500 Received: from mx1.redhat.com ([209.132.183.28]:59175) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQxR7-00085K-QI for qemu-devel@nongnu.org; Wed, 03 Feb 2016 08:25:33 -0500 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 6F8A87AE93 for ; Wed, 3 Feb 2016 13:25:33 +0000 (UTC) Date: Wed, 3 Feb 2016 13:25:29 +0000 From: "Daniel P. Berrange" Message-ID: <20160203132529.GK30222@redhat.com> References: <1452599056-27357-1-git-send-email-berrange@redhat.com> <1452599056-27357-14-git-send-email-berrange@redhat.com> <20160202200136.GF4498@work-vm> <20160203113727.GG30222@redhat.com> <20160203132303.GI2376@work-vm> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160203132303.GI2376@work-vm> Subject: Re: [Qemu-devel] [PATCH v1 13/22] migration: convert RDMA to use QIOChannel interface Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Dr. David Alan Gilbert" Cc: Amit Shah , qemu-devel@nongnu.org, Juan Quintela On Wed, Feb 03, 2016 at 01:23:04PM +0000, Dr. David Alan Gilbert wrote: > * Daniel P. Berrange (berrange@redhat.com) wrote: > > On Tue, Feb 02, 2016 at 08:01:36PM +0000, Dr. David Alan Gilbert wrote: > > > * Daniel P. Berrange (berrange@redhat.com) wrote: > > > > This converts the RDMA code to provide a subclass of > > > > QIOChannel that uses RDMA for the data transport. > > > > > > > > The RDMA code would be much better off it it could > > > > be split up in a generic RDMA layer, a QIOChannel > > > > impl based on RMDA, and then the RMDA migration > > > > glue. This is left as a future exercise for the brave. > > > > > > > > Signed-off-by: Daniel P. Berrange > > > > --- > > > > migration/rdma.c | 260 ++++++++++++++++++++++++++++++++++--------------------- > > > > 1 file changed, 161 insertions(+), 99 deletions(-) > > > > > > > > > > I don't quite understand the behaviour of this loop. > > > If rdma_fill returns less than you wanted for the first iov we break. > > > If it returns 0 then we try and get some more. > > > The weird thing to me is if we have two iov entries; if the > > > amount returned by the qemu_rdma_fill happens to match the size of > > > the 1st iov then I think we end up doing the exchange_recv and > > > waiting for more. Is that what we want? Why? > > > > No, it isn't quite what we want. If we have successfully received > > some data in a preceeding iov, then we shouldn't wait for more data > > for any following iov. I'll rework this bit of code to work better > > > > In fact technically, we should not block for data at all when the > > channel is in non-blocking mode. Fixing that would require some > > refactoring of qemu_rdma_block_for_wrid() so that we could tell > > it to only look for an already completed work request and not > > block > > I wouldn't go changing qemu_rdma_block_for_wrid unless you need > to. Yeah, I won't do it now - just something to think about for the future to properly do non-blocking I/o channels. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|