qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 2/4] multifd: document packet_len, next_packet_size


From: Fabiano Rosas
Subject: Re: [PATCH v2 2/4] multifd: document packet_len, next_packet_size
Date: Wed, 11 Oct 2023 16:04:13 -0300

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]