qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: Fabiano Rosas <farosas@suse.de>
Cc: qemu-devel@nongnu.org,
	"Maciej S . Szmigiero" <mail@maciej.szmigiero.name>
Subject: Re: [PATCH v3 13/14] migration/multifd: Register nocomp ops dynamically
Date: Thu, 22 Aug 2024 12:23:24 -0400	[thread overview]
Message-ID: <Zsdl_ADh-VTKV-wT@x1n> (raw)
In-Reply-To: <20240801123516.4498-14-farosas@suse.de>

On Thu, Aug 01, 2024 at 09:35:15AM -0300, Fabiano Rosas wrote:
> Prior to moving the ram code into multifd-ram.c, change the code to
> register the nocomp ops dynamically so we don't need to have the ops
> structure defined in multifd.c.
> 
> While here, rename s/nocomp/ram/ and remove the docstrings which are
> mostly useless (if anything, it's the function pointers in multifd.h
> that should be documented like that).
> 
> Signed-off-by: Fabiano Rosas <farosas@suse.de>
> ---
>  migration/multifd.c | 101 ++++++++++++--------------------------------
>  1 file changed, 28 insertions(+), 73 deletions(-)
> 
> diff --git a/migration/multifd.c b/migration/multifd.c
> index c25ab4924c..d5be784b6f 100644
> --- a/migration/multifd.c
> +++ b/migration/multifd.c
> @@ -167,15 +167,7 @@ static void multifd_set_file_bitmap(MultiFDSendParams *p)
>      }
>  }
>  
> -/* Multifd without compression */
> -
> -/**
> - * nocomp_send_setup: setup send side
> - *
> - * @p: Params for the channel that we are using
> - * @errp: pointer to an error
> - */
> -static int nocomp_send_setup(MultiFDSendParams *p, Error **errp)
> +static int ram_send_setup(MultiFDSendParams *p, Error **errp)

"ram" as a prefix sounds inaccurate to me.  Personally I even preferred the
old name "nocomp" because it says there's no compression.

Here "ram_send_setup" is at the same level against e.g. "zlib_send_setup".
It sounds like zlib isn't for ram, but it is..

Do you perhaps dislike the "nocomp" term?  How about:

  multifd_plain_send_setup()

Just to do s/nocomp/plain/?  Or "raw"?

We do have two flavours here at least:

*** migration/multifd-qpl.c:
<global>[755]                  .send_setup = multifd_qpl_send_setup,

*** migration/multifd-ram.c:
<global>[387]                  .send_setup = ram_send_setup,

*** migration/multifd-uadk.c:
<global>[364]                  .send_setup = multifd_uadk_send_setup,

*** migration/multifd-zlib.c:
<global>[338]                  .send_setup = zlib_send_setup,

*** migration/multifd-zstd.c:
<global>[326]                  .send_setup = zstd_send_setup,

It might makes sense to all prefix them with "multifd_", just to follow
gpl/uadk?

>  {
>      uint32_t page_count = multifd_ram_page_count();
>  
> @@ -193,15 +185,7 @@ static int nocomp_send_setup(MultiFDSendParams *p, Error **errp)
>      return 0;
>  }
>  
> -/**
> - * nocomp_send_cleanup: cleanup send side
> - *
> - * For no compression this function does nothing.
> - *
> - * @p: Params for the channel that we are using
> - * @errp: pointer to an error
> - */
> -static void nocomp_send_cleanup(MultiFDSendParams *p, Error **errp)
> +static void ram_send_cleanup(MultiFDSendParams *p, Error **errp)
>  {
>      g_free(p->iov);
>      p->iov = NULL;
> @@ -222,18 +206,7 @@ static void multifd_send_prepare_iovs(MultiFDSendParams *p)
>      p->next_packet_size = pages->normal_num * page_size;
>  }
>  
> -/**
> - * nocomp_send_prepare: prepare date to be able to send
> - *
> - * For no compression we just have to calculate the size of the
> - * packet.
> - *
> - * Returns 0 for success or -1 for error
> - *
> - * @p: Params for the channel that we are using
> - * @errp: pointer to an error
> - */
> -static int nocomp_send_prepare(MultiFDSendParams *p, Error **errp)
> +static int ram_send_prepare(MultiFDSendParams *p, Error **errp)
>  {
>      bool use_zero_copy_send = migrate_zero_copy_send();
>      int ret;
> @@ -272,46 +245,19 @@ static int nocomp_send_prepare(MultiFDSendParams *p, Error **errp)
>      return 0;
>  }
>  
> -/**
> - * nocomp_recv_setup: setup receive side
> - *
> - * For no compression this function does nothing.
> - *
> - * Returns 0 for success or -1 for error
> - *
> - * @p: Params for the channel that we are using
> - * @errp: pointer to an error
> - */
> -static int nocomp_recv_setup(MultiFDRecvParams *p, Error **errp)
> +static int ram_recv_setup(MultiFDRecvParams *p, Error **errp)
>  {
>      p->iov = g_new0(struct iovec, multifd_ram_page_count());
>      return 0;
>  }
>  
> -/**
> - * nocomp_recv_cleanup: setup receive side
> - *
> - * For no compression this function does nothing.
> - *
> - * @p: Params for the channel that we are using
> - */
> -static void nocomp_recv_cleanup(MultiFDRecvParams *p)
> +static void ram_recv_cleanup(MultiFDRecvParams *p)
>  {
>      g_free(p->iov);
>      p->iov = NULL;
>  }
>  
> -/**
> - * nocomp_recv: read the data from the channel
> - *
> - * For no compression we just need to read things into the correct place.
> - *
> - * Returns 0 for success or -1 for error
> - *
> - * @p: Params for the channel that we are using
> - * @errp: pointer to an error
> - */
> -static int nocomp_recv(MultiFDRecvParams *p, Error **errp)
> +static int ram_recv(MultiFDRecvParams *p, Error **errp)
>  {
>      uint32_t flags;
>  
> @@ -341,22 +287,15 @@ static int nocomp_recv(MultiFDRecvParams *p, Error **errp)
>      return qio_channel_readv_all(p->c, p->iov, p->normal_num, errp);
>  }
>  
> -static MultiFDMethods multifd_nocomp_ops = {
> -    .send_setup = nocomp_send_setup,
> -    .send_cleanup = nocomp_send_cleanup,
> -    .send_prepare = nocomp_send_prepare,
> -    .recv_setup = nocomp_recv_setup,
> -    .recv_cleanup = nocomp_recv_cleanup,
> -    .recv = nocomp_recv
> -};
> -
> -static MultiFDMethods *multifd_ops[MULTIFD_COMPRESSION__MAX] = {
> -    [MULTIFD_COMPRESSION_NONE] = &multifd_nocomp_ops,
> -};
> +static MultiFDMethods *multifd_ops[MULTIFD_COMPRESSION__MAX] = {};
>  
>  void multifd_register_ops(int method, MultiFDMethods *ops)
>  {
> -    assert(0 < method && method < MULTIFD_COMPRESSION__MAX);
> +    if (method == MULTIFD_COMPRESSION_NONE) {
> +        assert(!multifd_ops[method]);
> +    } else {
> +        assert(0 < method && method < MULTIFD_COMPRESSION__MAX);
> +    }
>      multifd_ops[method] = ops;
>  }

The new assertion is a bit paranoid to me.. while checking duplicated
assignment should at least apply to all if to add.  So.. how about:

  assert(method < MULTIFD_COMPRESSION__MAX);
  assert(!multifd_ops[method]);
  multifd_ops[method] = ops;

?

>  
> @@ -1755,3 +1694,19 @@ bool multifd_send_prepare_common(MultiFDSendParams *p)
>  
>      return true;
>  }
> +
> +static MultiFDMethods multifd_ram_ops = {
> +    .send_setup = ram_send_setup,
> +    .send_cleanup = ram_send_cleanup,
> +    .send_prepare = ram_send_prepare,
> +    .recv_setup = ram_recv_setup,
> +    .recv_cleanup = ram_recv_cleanup,
> +    .recv = ram_recv
> +};
> +
> +static void multifd_ram_register(void)
> +{
> +    multifd_register_ops(MULTIFD_COMPRESSION_NONE, &multifd_ram_ops);
> +}
> +
> +migration_init(multifd_ram_register);
> -- 
> 2.35.3
> 

-- 
Peter Xu



  reply	other threads:[~2024-08-22 16:24 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-01 12:35 [PATCH v3 00/14] migration/multifd: Remove multifd_send_state->pages Fabiano Rosas
2024-08-01 12:35 ` [PATCH v3 01/14] migration/multifd: Reduce access to p->pages Fabiano Rosas
2024-08-01 12:35 ` [PATCH v3 02/14] migration/multifd: Inline page_size and page_count Fabiano Rosas
2024-08-21 20:25   ` Peter Xu
2024-08-01 12:35 ` [PATCH v3 03/14] migration/multifd: Remove pages->allocated Fabiano Rosas
2024-08-21 20:32   ` Peter Xu
2024-08-01 12:35 ` [PATCH v3 04/14] migration/multifd: Pass in MultiFDPages_t to file_write_ramblock_iov Fabiano Rosas
2024-08-01 12:35 ` [PATCH v3 05/14] migration/multifd: Introduce MultiFDSendData Fabiano Rosas
2024-08-01 12:35 ` [PATCH v3 06/14] migration/multifd: Make MultiFDPages_t:offset a flexible array member Fabiano Rosas
2024-08-21 20:38   ` Peter Xu
2024-08-01 12:35 ` [PATCH v3 07/14] migration/multifd: Replace p->pages with an union pointer Fabiano Rosas
2024-08-21 21:27   ` Peter Xu
2024-08-01 12:35 ` [PATCH v3 08/14] migration/multifd: Move pages accounting into multifd_send_zero_page_detect() Fabiano Rosas
2024-08-01 12:35 ` [PATCH v3 09/14] migration/multifd: Isolate ram pages packet data Fabiano Rosas
2024-08-21 21:38   ` Peter Xu
2024-08-22 14:13     ` Fabiano Rosas
2024-08-22 14:30       ` Peter Xu
2024-08-22 14:55         ` Fabiano Rosas
2024-08-01 12:35 ` [PATCH v3 10/14] migration/multifd: Don't send ram data during SYNC Fabiano Rosas
2024-08-22 15:50   ` Peter Xu
2024-08-01 12:35 ` [PATCH v3 11/14] migration/multifd: Replace multifd_send_state->pages with client data Fabiano Rosas
2024-08-22 15:59   ` Peter Xu
2024-08-01 12:35 ` [PATCH v3 12/14] migration/multifd: Allow multifd sync without flush Fabiano Rosas
2024-08-22 16:03   ` Peter Xu
2024-08-22 16:10     ` Peter Xu
2024-08-22 17:05       ` Fabiano Rosas
2024-08-22 17:36         ` Peter Xu
2024-08-22 18:07           ` Fabiano Rosas
2024-08-22 19:11             ` Peter Xu
2024-08-01 12:35 ` [PATCH v3 13/14] migration/multifd: Register nocomp ops dynamically Fabiano Rosas
2024-08-22 16:23   ` Peter Xu [this message]
2024-08-22 17:20     ` Fabiano Rosas
2024-08-01 12:35 ` [PATCH v3 14/14] migration/multifd: Move ram code into multifd-ram.c Fabiano Rosas
2024-08-22 16:25   ` Peter Xu
2024-08-22 17:21     ` Fabiano Rosas
2024-08-22 17:27       ` Peter Xu
2024-08-01 12:45 ` [PATCH v3 00/14] migration/multifd: Remove multifd_send_state->pages Fabiano Rosas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Zsdl_ADh-VTKV-wT@x1n \
    --to=peterx@redhat.com \
    --cc=farosas@suse.de \
    --cc=mail@maciej.szmigiero.name \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).