Re: [Qemu-devel] [PATCH v1 13/22] migration: convert RDMA to use QIOChannel interface

[Daniel P. Berrange]

On Wed, Feb 03, 2016 at 01:23:04PM +0000, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrange (address@hidden) wrote:
> > On Tue, Feb 02, 2016 at 08:01:36PM +0000, Dr. David Alan Gilbert wrote:
> > > * Daniel P. Berrange (address@hidden) 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 <address@hidden>
> > > > ---
> > > >  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 :|