From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Tejus GK <tejus.gk@nutanix.com>
Cc: qemu-devel@nongnu.org, Manish Mishra <manish.mishra@nutanix.com>,
Peter Xu <peterx@redhat.com>, Fabiano Rosas <farosas@suse.de>
Subject: Re: [PATCH v7 2/2] QIOChannelSocket: flush zerocopy socket error queue on sendmsg failure due to ENOBUF
Date: Fri, 31 Oct 2025 13:59:32 +0000 [thread overview]
Message-ID: <aQTAxDBWPxcrj82g@redhat.com> (raw)
In-Reply-To: <20251024131546.929499-3-tejus.gk@nutanix.com>
On Fri, Oct 24, 2025 at 01:15:43PM +0000, Tejus GK wrote:
> From: Manish Mishra <manish.mishra@nutanix.com>
>
> The kernel allocates extra metadata SKBs in case of a zerocopy send,
> eventually used for zerocopy's notification mechanism. This metadata
> memory is accounted for in the OPTMEM limit. The kernel queues
> completion notifications on the socket error queue and this error queue
> is freed when userspace reads it.
>
> Usually, in the case of in-order processing, the kernel will batch the
> notifications and merge the metadata into a single SKB and free the
> rest. As a result, it never exceeds the OPTMEM limit. However, if there
> is any out-of-order processing or intermittent zerocopy failures, this
> error chain can grow significantly, exhausting the OPTMEM limit. As a
> result, all new sendmsg requests fail to allocate any new SKB, leading
> to an ENOBUF error. Depending on the amount of data queued before the
> flush (i.e., large live migration iterations), even large OPTMEM limits
> are prone to failure.
>
> To work around this, if we encounter an ENOBUF error with a zerocopy
> sendmsg, flush the error queue and retry once more.
>
> Co-authored-by: Manish Mishra <manish.mishra@nutanix.com>
> Signed-off-by: Tejus GK <tejus.gk@nutanix.com>
> ---
> include/io/channel-socket.h | 5 +++
> io/channel-socket.c | 80 ++++++++++++++++++++++++++++++-------
> 2 files changed, 71 insertions(+), 14 deletions(-)
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> SocketAddress *
> qio_channel_socket_get_local_address(QIOChannelSocket *ioc,
> Error **errp)
> @@ -66,6 +72,7 @@ qio_channel_socket_new(void)
> sioc->zero_copy_queued = 0;
> sioc->zero_copy_sent = 0;
> sioc->blocking = false;
> + sioc->new_zero_copy_sent_success = FALSE;
Needs to be 'false'
>
> ioc = QIO_CHANNEL(sioc);
> qio_channel_set_feature(ioc, QIO_CHANNEL_FEATURE_SHUTDOWN);
> @@ -618,6 +625,8 @@ static ssize_t qio_channel_socket_writev(QIOChannel *ioc,
> size_t fdsize = sizeof(int) * nfds;
> struct cmsghdr *cmsg;
> int sflags = 0;
> + bool blocking = sioc->blocking;
> + bool zerocopy_flushed_once = false;
>
> memset(control, 0, CMSG_SPACE(sizeof(int) * SOCKET_MAX_FDS));
>
> @@ -664,9 +673,24 @@ static ssize_t qio_channel_socket_writev(QIOChannel *ioc,
> goto retry;
> case ENOBUFS:
> if (flags & QIO_CHANNEL_WRITE_FLAG_ZERO_COPY) {
> - error_setg_errno(errp, errno,
> - "Process can't lock enough memory for using MSG_ZEROCOPY");
> - return -1;
> + /**
> + * Socket error queueing may exhaust the OPTMEM limit. Try
> + * flushing the error queue once.
> + */
> + if (!zerocopy_flushed_once) {
> + ret = qio_channel_socket_flush_internal(ioc, blocking,
> + errp);
> + if (ret < 0) {
> + return -1;
> + }
> + zerocopy_flushed_once = TRUE;
... 'true'..
> @@ -843,13 +876,32 @@ static int qio_channel_socket_flush(QIOChannel *ioc,
> /* No errors, count successfully finished sendmsg()*/
> sioc->zero_copy_sent += serr->ee_data - serr->ee_info + 1;
>
> - /* If any sendmsg() succeeded using zero copy, return 0 at the end */
> + /* If any sendmsg() succeeded using zero copy, mark zerocopy success */
> if (serr->ee_code != SO_EE_CODE_ZEROCOPY_COPIED) {
> - ret = 0;
> + sioc->new_zero_copy_sent_success = TRUE;
...true...
> }
> }
>
> - return ret;
> + return 0;
> +}
> +
> +static int qio_channel_socket_flush(QIOChannel *ioc,
> + Error **errp)
> +{
> + QIOChannelSocket *sioc = QIO_CHANNEL_SOCKET(ioc);
> + int ret;
> +
> + ret = qio_channel_socket_flush_internal(ioc, true, errp);
> + if (ret < 0) {
> + return ret;
> + }
> +
> + if (sioc->new_zero_copy_sent_success) {
> + sioc->new_zero_copy_sent_success = FALSE;
...false....
Since these are trivial changes, i'll make them when applying this
patch, so no need to re-send.
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 :|
prev parent reply other threads:[~2025-10-31 14:00 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-24 13:15 [PATCH v7 0/2] Add zerocopy partial flush support for live migrations Tejus GK
2025-10-24 13:15 ` [PATCH v7 1/2] QIOChannelSocket: add a "blocking" field to QIOChannelSocket Tejus GK
2025-10-24 13:15 ` [PATCH v7 2/2] QIOChannelSocket: flush zerocopy socket error queue on sendmsg failure due to ENOBUF Tejus GK
2025-10-31 13:59 ` Daniel P. Berrangé [this message]
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=aQTAxDBWPxcrj82g@redhat.com \
--to=berrange@redhat.com \
--cc=farosas@suse.de \
--cc=manish.mishra@nutanix.com \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=tejus.gk@nutanix.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 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).