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 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).