Thanks for your review. I will merge this with multifd.
-----Original Message-----
From: Juan Quintela [mailto:quint...@redhat.com]
Sent: Thursday, January 16, 2020 9:25 PM
To: fengzhimin <fengzhim...@huawei.com>
Cc: dgilb...@redhat.com; arm...@redhat.com; ebl...@redhat.com;
qemu-devel@nongnu.org; Zhanghailiang <zhang.zhanghaili...@huawei.com>;
jemmy858...@gmail.com
Subject: Re: [PATCH RFC 04/12] migration/rdma: Create multiRDMA migration
threads
Zhimin Feng <fengzhim...@huawei.com> wrote:
> From: fengzhimin <fengzhim...@huawei.com>
>
> Creation of the RDMA threads, nothing inside yet.
>
> Signed-off-by: fengzhimin <fengzhim...@huawei.com>
> ---
> migration/migration.c | 1 +
> migration/migration.h | 2 +
> migration/rdma.c | 283 ++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 286 insertions(+)
>
> diff --git a/migration/migration.c b/migration/migration.c index
> 5756a4806e..f8d4eb657e 100644
> --- a/migration/migration.c
> +++ b/migration/migration.c
> @@ -1546,6 +1546,7 @@ static void migrate_fd_cleanup(MigrationState *s)
> qemu_mutex_lock_iothread();
>
> multifd_save_cleanup();
> + multiRDMA_save_cleanup();
Can we merge this with multifd?
> +typedef struct {
> + /* this fields are not changed once the thread is created */
> + /* channel number */
> + uint8_t id;
> + /* channel thread name */
> + char *name;
> + /* channel thread id */
> + QemuThread thread;
> + /* sem where to wait for more work */
> + QemuSemaphore sem;
> + /* this mutex protects the following parameters */
> + QemuMutex mutex;
> + /* is this channel thread running */
> + bool running;
> + /* should this thread finish */
> + bool quit;
> +} MultiRDMASendParams;
This is basically the same than MultiFBSendParams, same for the rest.
I would very much preffer not to have two sets of threads that are really
equivalent.
Thanks, Juan.
