Re: [PATCH v2] QIOChannelSocket: Flush zerocopy socket error queue on ENOBUF failure for sendmsg

["Daniel P. Berrangé" <berrange@redhat.com>]

On Mon, Mar 10, 2025 at 03:12:05PM -0400, Peter Xu wrote:
> On Sun, Mar 09, 2025 at 09:15:00PM -0400, Manish Mishra wrote:
> > We allocate extra metadata SKBs in case of a zerocopy send. This metadata
> > memory is accounted for in the OPTMEM limit. If there is any error while
> > sending zerocopy packets or if zerocopy is skipped, these metadata SKBs are
> > queued in the socket error queue. This error queue is freed when userspace
> > reads it.
> > 
> > Usually, if there are continuous failures, we merge the metadata into a single
> > SKB and free another one. 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,
> > we flush the error queue and retry once more.
> > 
> > Additionally, this patch removes the dirty_sync_missed_zero_copy migration
> > stat. This stat is not used anywhere and does not seem useful. Removing it
> > simplifies the patch.
> 
> IMHO it's still useful, it's just that if it's for debugging purpose, it's
> optional to expose it via QAPI.  Then if without exposing it to upper
> layer, it can simplify the change this patch wanted to introduce.  We can
> still keep it a tracepoint.


> > diff --git a/migration/multifd.c b/migration/multifd.c
> > index dfb5189f0e..ee6b2d3cba 100644
> > --- a/migration/multifd.c
> > +++ b/migration/multifd.c
> > @@ -607,9 +607,6 @@ static int multifd_zero_copy_flush(QIOChannel *c)
> >          error_report_err(err);
> >          return -1;
> >      }
> > -    if (ret == 1) {
> > -        stat64_add(&mig_stats.dirty_sync_missed_zero_copy, 1);
> > -    }
> 
> If we want to remove this, we need to remove the variable in QAPI too.
> 
> # @dirty-sync-missed-zero-copy: Number of times dirty RAM
> #     synchronization could not avoid copying dirty pages.  This is
> #     between 0 and @dirty-sync-count * @multifd-channels.  (since
> #     7.1)
> 
> Personally I'd remove it directly, but others may not always agree... in
> this case, the safe approach is to mark it deprecate and update this in
> docs/about/deprecated.rst.  Then you can leave it to us to finally remove
> this entry (or send another patch after two qemu releases).

Given this is in public API, the data needs to remain reported accurately
for the whole deprecation period. IOW, the patch to qiochannel needs to
preserve this data too.


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 :|