[Qemu-devel] [PATCH v2 3/5] migration: do explicit incoming setup for rdma

Peter Xu posted 5 patches 7 years, 7 months ago
There is a newer version of this series
[Qemu-devel] [PATCH v2 3/5] migration: do explicit incoming setup for rdma
Posted by Peter Xu 7 years, 7 months ago
RDMA does not support postcopy recovery, so no need to go into such
logic.  Instead of calling migration_fd_process_incoming(), let's call
the two functions that setup the incoming migration.  There should have
no functional change at all.

Signed-off-by: Peter Xu <peterx@redhat.com>
---
 migration/rdma.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/migration/rdma.c b/migration/rdma.c
index 8bd7159059..217cdd7dd8 100644
--- a/migration/rdma.c
+++ b/migration/rdma.c
@@ -3687,7 +3687,8 @@ static void rdma_accept_incoming_migration(void *opaque)
     }
 
     rdma->migration_started_on_destination = 1;
-    migration_fd_process_incoming(f);
+    migration_incoming_setup(f);
+    migration_incoming_process();
 }
 
 void rdma_start_incoming_migration(const char *host_port, Error **errp)
-- 
2.17.1


Re: [Qemu-devel] [PATCH v2 3/5] migration: do explicit incoming setup for rdma
Posted by Dr. David Alan Gilbert 7 years, 7 months ago
* Peter Xu (peterx@redhat.com) wrote:
> RDMA does not support postcopy recovery, so no need to go into such
> logic.  Instead of calling migration_fd_process_incoming(), let's call
> the two functions that setup the incoming migration.  There should have
> no functional change at all.

Can you explain why we need to though?  The reason I ask is that there
is Lidong Chen's work that gets postcopy partially working with RDMA, so
then the next question is bound to be recovery.

Dave

> Signed-off-by: Peter Xu <peterx@redhat.com>
> ---
>  migration/rdma.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/migration/rdma.c b/migration/rdma.c
> index 8bd7159059..217cdd7dd8 100644
> --- a/migration/rdma.c
> +++ b/migration/rdma.c
> @@ -3687,7 +3687,8 @@ static void rdma_accept_incoming_migration(void *opaque)
>      }
>  
>      rdma->migration_started_on_destination = 1;
> -    migration_fd_process_incoming(f);
> +    migration_incoming_setup(f);
> +    migration_incoming_process();
>  }
>  
>  void rdma_start_incoming_migration(const char *host_port, Error **errp)
> -- 
> 2.17.1
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

Re: [Qemu-devel] [PATCH v2 3/5] migration: do explicit incoming setup for rdma
Posted by Peter Xu 7 years, 7 months ago
On Wed, Jun 27, 2018 at 01:25:45PM +0100, Dr. David Alan Gilbert wrote:
> * Peter Xu (peterx@redhat.com) wrote:
> > RDMA does not support postcopy recovery, so no need to go into such
> > logic.  Instead of calling migration_fd_process_incoming(), let's call
> > the two functions that setup the incoming migration.  There should have
> > no functional change at all.
> 
> Can you explain why we need to though?  The reason I ask is that there
> is Lidong Chen's work that gets postcopy partially working with RDMA, so
> then the next question is bound to be recovery.

Ah if so this patch needs to change.  Could you paste me the message
id of the work?  Or link?

After all I'll need to keep this bit, but I am just curious about what
is "partially" mean here. :)

Thanks,

-- 
Peter Xu

Re: [Qemu-devel] [PATCH v2 3/5] migration: do explicit incoming setup for rdma
Posted by Dr. David Alan Gilbert 7 years, 7 months ago
* Peter Xu (peterx@redhat.com) wrote:
> On Wed, Jun 27, 2018 at 01:25:45PM +0100, Dr. David Alan Gilbert wrote:
> > * Peter Xu (peterx@redhat.com) wrote:
> > > RDMA does not support postcopy recovery, so no need to go into such
> > > logic.  Instead of calling migration_fd_process_incoming(), let's call
> > > the two functions that setup the incoming migration.  There should have
> > > no functional change at all.
> > 
> > Can you explain why we need to though?  The reason I ask is that there
> > is Lidong Chen's work that gets postcopy partially working with RDMA, so
> > then the next question is bound to be recovery.
> 
> Ah if so this patch needs to change.  Could you paste me the message
> id of the work?  Or link?
> 
> After all I'll need to keep this bit, but I am just curious about what
> is "partially" mean here. :)

https://patchwork.ozlabs.org/cover/925525/

It enables postcopy with RDMA, but once it switches into postcopy mode
it doesn't use the fast features of RDMA, it still shuffles the data
as a stream (using some more basic RDMA features).

Dave

> Thanks,
> 
> -- 
> Peter Xu
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

Re: [Qemu-devel] [PATCH v2 3/5] migration: do explicit incoming setup for rdma
Posted by Peter Xu 7 years, 7 months ago
On Wed, Jun 27, 2018 at 03:13:04PM +0100, Dr. David Alan Gilbert wrote:
> * Peter Xu (peterx@redhat.com) wrote:
> > On Wed, Jun 27, 2018 at 01:25:45PM +0100, Dr. David Alan Gilbert wrote:
> > > * Peter Xu (peterx@redhat.com) wrote:
> > > > RDMA does not support postcopy recovery, so no need to go into such
> > > > logic.  Instead of calling migration_fd_process_incoming(), let's call
> > > > the two functions that setup the incoming migration.  There should have
> > > > no functional change at all.
> > > 
> > > Can you explain why we need to though?  The reason I ask is that there
> > > is Lidong Chen's work that gets postcopy partially working with RDMA, so
> > > then the next question is bound to be recovery.
> > 
> > Ah if so this patch needs to change.  Could you paste me the message
> > id of the work?  Or link?
> > 
> > After all I'll need to keep this bit, but I am just curious about what
> > is "partially" mean here. :)
> 
> https://patchwork.ozlabs.org/cover/925525/
> 
> It enables postcopy with RDMA, but once it switches into postcopy mode
> it doesn't use the fast features of RDMA, it still shuffles the data
> as a stream (using some more basic RDMA features).

Ah so it's not really partial but relatively complete, though it seems
that there can be further performance work on top.  That's an
interesting work, thanks for the pointer.

-- 
Peter Xu