From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Leonardo Bras <leobras@redhat.com>
Cc: Juan Quintela <quintela@redhat.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
Peter Xu <peterx@redhat.com>,
qemu-devel@nongnu.org
Subject: Re: [PATCH v1 2/2] migration/multifd: Warn user when zerocopy not working
Date: Tue, 28 Jun 2022 08:53:40 +0100 [thread overview]
Message-ID: <YrqzhFAePnnEl8A8@redhat.com> (raw)
In-Reply-To: <20220628010908.390564-3-leobras@redhat.com>
On Mon, Jun 27, 2022 at 10:09:09PM -0300, Leonardo Bras wrote:
> Some errors, like the lack of Scatter-Gather support by the network
> interface(NETIF_F_SG) may cause sendmsg(...,MSG_ZEROCOPY) to fail on using
> zero-copy, which causes it to fall back to the default copying mechanism.
How common is this lack of SG support ? What NICs did you have that
were affected ?
> After each full dirty-bitmap scan there should be a zero-copy flush
> happening, which checks for errors each of the previous calls to
> sendmsg(...,MSG_ZEROCOPY). If all of them failed to use zero-copy, then
> warn the user about it.
>
> Since it happens once each full dirty-bitmap scan, even in worst case
> scenario it should not print a lot of warnings, and will allow tracking
> how many dirty-bitmap iterations were not able to use zero-copy send.
For long running migrations which are not converging, or converging
very slowly there could be 100's of passes.
> Signed-off-by: Leonardo Bras <leobras@redhat.com>
> ---
> migration/multifd.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/migration/multifd.c b/migration/multifd.c
> index 684c014c86..9c62aec84e 100644
> --- a/migration/multifd.c
> +++ b/migration/multifd.c
> @@ -624,6 +624,9 @@ int multifd_send_sync_main(QEMUFile *f)
> if (ret < 0) {
> error_report_err(err);
> return -1;
> + } else if (ret == 1) {
> + warn_report("The network device is not able to use "
> + "zero-copy-send: copying is being used");
> }
> }
> }
> --
> 2.36.1
>
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2022-06-28 8:40 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-28 1:09 [PATCH v1 0/2] Zero copy improvements (QIOChannel + multifd) Leonardo Bras
2022-06-28 1:09 ` [PATCH v1 1/2] QIOChannelSocket: Fix zero-copy flush returning code 1 when nothing sent Leonardo Bras
2022-06-28 1:09 ` [PATCH v1 2/2] migration/multifd: Warn user when zerocopy not working Leonardo Bras
2022-06-28 7:53 ` Daniel P. Berrangé [this message]
2022-06-28 12:32 ` Leonardo Bras Soares Passos
2022-06-28 13:02 ` Daniel P. Berrangé
2022-06-28 13:52 ` Dr. David Alan Gilbert
2022-06-28 16:53 ` Leonardo Bras Soares Passos
2022-06-28 16:56 ` Dr. David Alan Gilbert
2022-07-01 6:18 ` Leonardo Brás
2022-07-04 9:19 ` Dr. David Alan Gilbert
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=YrqzhFAePnnEl8A8@redhat.com \
--to=berrange@redhat.com \
--cc=dgilbert@redhat.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.