| Message ID | 1523089594-1422-3-git-send-email-lidongchen@tencent.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
* Lidong Chen (jemmy858585@gmail.com) wrote: > The default get_return_path function of iochannel does not work for > RDMA live migration. So add the interface to set get_return_path. > > Signed-off-by: Lidong Chen <lidongchen@tencent.com> Lets see how Dan wants this done, he knows the channel/file stuff; to me this feels like it should be adding a member to QIOChannelClass that gets used by QEMUFile's get_return_path. (Dan and see next patch) Dave > --- > migration/qemu-file-channel.c | 12 ++++++++---- > migration/qemu-file.c | 10 ++++++++-- > migration/qemu-file.h | 2 +- > 3 files changed, 17 insertions(+), 7 deletions(-) > > diff --git a/migration/qemu-file-channel.c b/migration/qemu-file-channel.c > index e202d73..d4dd8c4 100644 > --- a/migration/qemu-file-channel.c > +++ b/migration/qemu-file-channel.c > @@ -156,7 +156,6 @@ static const QEMUFileOps channel_input_ops = { > .close = channel_close, > .shut_down = channel_shutdown, > .set_blocking = channel_set_blocking, > - .get_return_path = channel_get_input_return_path, > }; > > > @@ -165,18 +164,23 @@ static const QEMUFileOps channel_output_ops = { > .close = channel_close, > .shut_down = channel_shutdown, > .set_blocking = channel_set_blocking, > - .get_return_path = channel_get_output_return_path, > }; > > > QEMUFile *qemu_fopen_channel_input(QIOChannel *ioc) > { > + QEMUFile *f; > object_ref(OBJECT(ioc)); > - return qemu_fopen_ops(ioc, &channel_input_ops); > + f = qemu_fopen_ops(ioc, &channel_input_ops); > + qemu_file_set_return_path(f, channel_get_input_return_path); > + return f; > } > > QEMUFile *qemu_fopen_channel_output(QIOChannel *ioc) > { > + QEMUFile *f; > object_ref(OBJECT(ioc)); > - return qemu_fopen_ops(ioc, &channel_output_ops); > + f = qemu_fopen_ops(ioc, &channel_output_ops); > + qemu_file_set_return_path(f, channel_get_output_return_path); > + return f; > } > diff --git a/migration/qemu-file.c b/migration/qemu-file.c > index bb63c77..8acb574 100644 > --- a/migration/qemu-file.c > +++ b/migration/qemu-file.c > @@ -36,6 +36,7 @@ > struct QEMUFile { > const QEMUFileOps *ops; > const QEMUFileHooks *hooks; > + QEMURetPathFunc *get_return_path; > void *opaque; > > int64_t bytes_xfer; > @@ -72,10 +73,15 @@ int qemu_file_shutdown(QEMUFile *f) > */ > QEMUFile *qemu_file_get_return_path(QEMUFile *f) > { > - if (!f->ops->get_return_path) { > + if (!f->get_return_path) { > return NULL; > } > - return f->ops->get_return_path(f->opaque); > + return f->get_return_path(f->opaque); > +} > + > +void qemu_file_set_return_path(QEMUFile *f, QEMURetPathFunc *get_return_path) > +{ > + f->get_return_path = get_return_path; > } > > bool qemu_file_mode_is_not_valid(const char *mode) > diff --git a/migration/qemu-file.h b/migration/qemu-file.h > index f4f356a..74210b7 100644 > --- a/migration/qemu-file.h > +++ b/migration/qemu-file.h > @@ -102,7 +102,6 @@ typedef struct QEMUFileOps { > QEMUFileCloseFunc *close; > QEMUFileSetBlocking *set_blocking; > QEMUFileWritevBufferFunc *writev_buffer; > - QEMURetPathFunc *get_return_path; > QEMUFileShutdownFunc *shut_down; > } QEMUFileOps; > > @@ -114,6 +113,7 @@ typedef struct QEMUFileHooks { > } QEMUFileHooks; > > QEMUFile *qemu_fopen_ops(void *opaque, const QEMUFileOps *ops); > +void qemu_file_set_return_path(QEMUFile *f, QEMURetPathFunc *get_return_path); > void qemu_file_set_hooks(QEMUFile *f, const QEMUFileHooks *hooks); > int qemu_get_fd(QEMUFile *f); > int qemu_fclose(QEMUFile *f); > -- > 1.8.3.1 > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
On Wed, Apr 11, 2018 at 06:18:18PM +0100, Dr. David Alan Gilbert wrote: > * Lidong Chen (jemmy858585@gmail.com) wrote: > > The default get_return_path function of iochannel does not work for > > RDMA live migration. So add the interface to set get_return_path. > > > > Signed-off-by: Lidong Chen <lidongchen@tencent.com> > > Lets see how Dan wants this done, he knows the channel/file stuff; > to me this feels like it should be adding a member to QIOChannelClass > that gets used by QEMUFile's get_return_path. No that doesn't really fit the model. IMHO the entire concept of a separate return path object is really wrong. The QIOChannel implementations are (almost) all capable of bi-directional I/O, which is why the the get_retun_path function just creates a second QEMUFile pointing to the same QIOChannel object we already had. Migration only needs the second QEMUFile, because that struct re-uses the same struct fields for tracking different bits of info depending on which direction you're doing I/O in. A real fix would be to stop overloading the same fields for multiple purposes in the QEMUFile, so that we only needed a single QEMUFile instance. Ignoring that though, the particular problem we're facing here is that the QIOChannelRDMA impl that is used is not written in a way that allows bi-directional I/O, despite the RDMA code it uses being capable of it. So rather than changing this get_return_path code, IMHO, the right fix to simply improve the QIOChannelRDMA impl so that it fully supports bi-directional I/O like all the other channels do. Regards, Daniel
On Thu, Apr 12, 2018 at 4:28 PM, Daniel P. Berrangé <berrange@redhat.com> wrote: > On Wed, Apr 11, 2018 at 06:18:18PM +0100, Dr. David Alan Gilbert wrote: >> * Lidong Chen (jemmy858585@gmail.com) wrote: >> > The default get_return_path function of iochannel does not work for >> > RDMA live migration. So add the interface to set get_return_path. >> > >> > Signed-off-by: Lidong Chen <lidongchen@tencent.com> >> >> Lets see how Dan wants this done, he knows the channel/file stuff; >> to me this feels like it should be adding a member to QIOChannelClass >> that gets used by QEMUFile's get_return_path. > > No that doesn't really fit the model. IMHO the entire concept of a separate > return path object is really wrong. The QIOChannel implementations are > (almost) all capable of bi-directional I/O, which is why the the get_retun_path > function just creates a second QEMUFile pointing to the same QIOChannel > object we already had. Migration only needs the second QEMUFile, because that > struct re-uses the same struct fields for tracking different bits of info > depending on which direction you're doing I/O in. A real fix would be to > stop overloading the same fields for multiple purposes in the QEMUFile, so > that we only needed a single QEMUFile instance. > > Ignoring that though, the particular problem we're facing here is that the > QIOChannelRDMA impl that is used is not written in a way that allows > bi-directional I/O, despite the RDMA code it uses being capable of it. > > So rather than changing this get_return_path code, IMHO, the right fix to > simply improve the QIOChannelRDMA impl so that it fully supports bi-directional > I/O like all the other channels do. Hi Daniel: Thanks for your suggestion. I will have a try. > > Regards, > Daniel > -- > |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o- https://fstop138.berrange.com :| > |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
diff --git a/migration/qemu-file-channel.c b/migration/qemu-file-channel.c index e202d73..d4dd8c4 100644 --- a/migration/qemu-file-channel.c +++ b/migration/qemu-file-channel.c @@ -156,7 +156,6 @@ static const QEMUFileOps channel_input_ops = { .close = channel_close, .shut_down = channel_shutdown, .set_blocking = channel_set_blocking, - .get_return_path = channel_get_input_return_path, }; @@ -165,18 +164,23 @@ static const QEMUFileOps channel_output_ops = { .close = channel_close, .shut_down = channel_shutdown, .set_blocking = channel_set_blocking, - .get_return_path = channel_get_output_return_path, }; QEMUFile *qemu_fopen_channel_input(QIOChannel *ioc) { + QEMUFile *f; object_ref(OBJECT(ioc)); - return qemu_fopen_ops(ioc, &channel_input_ops); + f = qemu_fopen_ops(ioc, &channel_input_ops); + qemu_file_set_return_path(f, channel_get_input_return_path); + return f; } QEMUFile *qemu_fopen_channel_output(QIOChannel *ioc) { + QEMUFile *f; object_ref(OBJECT(ioc)); - return qemu_fopen_ops(ioc, &channel_output_ops); + f = qemu_fopen_ops(ioc, &channel_output_ops); + qemu_file_set_return_path(f, channel_get_output_return_path); + return f; } diff --git a/migration/qemu-file.c b/migration/qemu-file.c index bb63c77..8acb574 100644 --- a/migration/qemu-file.c +++ b/migration/qemu-file.c @@ -36,6 +36,7 @@ struct QEMUFile { const QEMUFileOps *ops; const QEMUFileHooks *hooks; + QEMURetPathFunc *get_return_path; void *opaque; int64_t bytes_xfer; @@ -72,10 +73,15 @@ int qemu_file_shutdown(QEMUFile *f) */ QEMUFile *qemu_file_get_return_path(QEMUFile *f) { - if (!f->ops->get_return_path) { + if (!f->get_return_path) { return NULL; } - return f->ops->get_return_path(f->opaque); + return f->get_return_path(f->opaque); +} + +void qemu_file_set_return_path(QEMUFile *f, QEMURetPathFunc *get_return_path) +{ + f->get_return_path = get_return_path; } bool qemu_file_mode_is_not_valid(const char *mode) diff --git a/migration/qemu-file.h b/migration/qemu-file.h index f4f356a..74210b7 100644 --- a/migration/qemu-file.h +++ b/migration/qemu-file.h @@ -102,7 +102,6 @@ typedef struct QEMUFileOps { QEMUFileCloseFunc *close; QEMUFileSetBlocking *set_blocking; QEMUFileWritevBufferFunc *writev_buffer; - QEMURetPathFunc *get_return_path; QEMUFileShutdownFunc *shut_down; } QEMUFileOps; @@ -114,6 +113,7 @@ typedef struct QEMUFileHooks { } QEMUFileHooks; QEMUFile *qemu_fopen_ops(void *opaque, const QEMUFileOps *ops); +void qemu_file_set_return_path(QEMUFile *f, QEMURetPathFunc *get_return_path); void qemu_file_set_hooks(QEMUFile *f, const QEMUFileHooks *hooks); int qemu_get_fd(QEMUFile *f); int qemu_fclose(QEMUFile *f);
The default get_return_path function of iochannel does not work for RDMA live migration. So add the interface to set get_return_path. Signed-off-by: Lidong Chen <lidongchen@tencent.com> --- migration/qemu-file-channel.c | 12 ++++++++---- migration/qemu-file.c | 10 ++++++++-- migration/qemu-file.h | 2 +- 3 files changed, 17 insertions(+), 7 deletions(-)