[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v1 13/22] migration: convert RDMA to use QIOChan
From: |
Daniel P. Berrange |
Subject: |
Re: [Qemu-devel] [PATCH v1 13/22] migration: convert RDMA to use QIOChannel interface |
Date: |
Wed, 3 Feb 2016 13:25:29 +0000 |
User-agent: |
Mutt/1.5.24 (2015-08-30) |
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 :|