On Fri, Oct 24, 2025 at 01:15:43PM +0000, Tejus GK wrote: > From: Manish Mishra <[email protected]> > > 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 <[email protected]> > Signed-off-by: Tejus GK <[email protected]> > --- > include/io/channel-socket.h | 5 +++ > io/channel-socket.c | 80 ++++++++++++++++++++++++++++++------- > 2 files changed, 71 insertions(+), 14 deletions(-)
Signed-off-by: Daniel P. Berrangé <[email protected]> > 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 :|
