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