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
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.