From: Fabiano Rosas <farosas@suse.de>
To: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Cc: quintela@redhat.com, peterx@redhat.com, leobras@redhat.com,
qemu-devel@nongnu.org
Subject: Re: [PATCH v2 2/4] multifd: document packet_len, next_packet_size
Date: Wed, 11 Oct 2023 16:04:13 -0300 [thread overview]
Message-ID: <87a5sp0ymq.fsf@suse.de> (raw)
In-Reply-To: <20231011184358.97349-3-elena.ufimtseva@oracle.com>
Elena Ufimtseva <elena.ufimtseva@oracle.com> writes:
> next_packet_size name is a bit misleading, so add more comments
> where its defined.
> We send data in two chunks in multifd thread:
> - send the packet with normal (non-zero) guest pages offsets that are
> dirty.
> This uses the packet_len and we increment number of packets
> for this thread that are sent;
> - send the normal (non-zero) guest dirty pages themselves in iovs.
> The total size of the data pointed by all iovs for this chunk
> is next_packet_size. We do not increment the packet_num for this
> thread when sending actual pages;
>
> When compression is enabled, next_packet_size is used to indicate
> the size of the compressed buffer on source and destination.
>
> Will be it helpful to rename it as data_size or dirty_data_size?
>
> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
> ---
> migration/multifd.h | 35 ++++++++++++++++++++++++++++++-----
> 1 file changed, 30 insertions(+), 5 deletions(-)
>
> diff --git a/migration/multifd.h b/migration/multifd.h
> index a835643b48..37da9b68c2 100644
> --- a/migration/multifd.h
> +++ b/migration/multifd.h
> @@ -45,7 +45,13 @@ typedef struct {
> uint32_t pages_alloc;
> /* non zero pages */
> uint32_t normal_pages;
> - /* size of the next packet that contains pages */
> + /*
> + * amount of data to be sent to the destination
> + * that is calculated as
> + * - number of the normal guest dirty pages * page_size in non
> + * compression case;
> + * - equals of the compressed data size to be received;
> + */
> uint32_t next_packet_size;
So maybe "payload_size"? This one, not the "next".
Let's see what other people think, but I'm in favor of just renaming
instead of documenting. Later on the maths change and the comment might
become off-sync with the code.
next prev parent reply other threads:[~2023-10-11 19:04 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-11 18:43 [PATCH v2 0/4] multifd: various fixes Elena Ufimtseva
2023-10-11 18:43 ` [PATCH v2 1/4] migration: check for rate_limit_max for RATE_LIMIT_DISABLED Elena Ufimtseva
2023-10-16 7:23 ` Juan Quintela
2023-10-11 18:43 ` [PATCH v2 2/4] multifd: document packet_len, next_packet_size Elena Ufimtseva
2023-10-11 19:04 ` Fabiano Rosas [this message]
2023-10-11 18:43 ` [PATCH v2 3/4] multifd: fix counters in multifd_send_thread Elena Ufimtseva
2023-10-16 7:25 ` Juan Quintela
2023-10-11 18:43 ` [PATCH v2 4/4] multifd: reset next_packet_len after sending pages Elena Ufimtseva
2023-10-16 7:26 ` Juan Quintela
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=87a5sp0ymq.fsf@suse.de \
--to=farosas@suse.de \
--cc=elena.ufimtseva@oracle.com \
--cc=leobras@redhat.com \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
/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.