Re: [Qemu-devel] [PATCH 2/5] migration: add the interface to set get_return_path

2018-04-12 Thread 858585 jemmy 
On Thu, Apr 12, 2018 at 4:28 PM, Daniel P. Berrangé  wrote:
> On Wed, Apr 11, 2018 at 06:18:18PM +0100, Dr. David Alan Gilbert wrote:
>> * Lidong Chen (jemmy858...@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 
>>
>> 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 :|

Re: [Qemu-devel] [PATCH 2/5] migration: add the interface to set get_return_path

2018-04-12 Thread Daniel P . Berrangé 
On Wed, Apr 11, 2018 at 06:18:18PM +0100, Dr. David Alan Gilbert wrote:
> * Lidong Chen (jemmy858...@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 
> 
> 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
-- 
|: 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 :|

Re: [Qemu-devel] [PATCH 2/5] migration: add the interface to set get_return_path

2018-04-11 Thread Dr. David Alan Gilbert 
* Lidong Chen (jemmy858...@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 

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, _input_ops);
> +f = qemu_fopen_ops(ioc, _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, _output_ops);
> +f = qemu_fopen_ops(ioc, _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 / dgilb...@redhat.com / Manchester, UK