On Mon, Mar 09, 2026 at 12:59:44PM -0400, Peter Xu wrote:
> On Mon, Mar 09, 2026 at 04:48:37PM +0000, Daniel P. Berrangé wrote:
> > > @@ -881,8 +881,8 @@ static int
> > > qio_channel_socket_flush_internal(QIOChannel *ioc,
> > > sioc->zero_copy_sent += serr->ee_data - serr->ee_info + 1;
> > >
> > > /* If any sendmsg() succeeded using zero copy, mark zerocopy
> > > success */
> > > - if (serr->ee_code != SO_EE_CODE_ZEROCOPY_COPIED) {
> > > - sioc->new_zero_copy_sent_success = true;
> > > + if (serr->ee_code == SO_EE_CODE_ZEROCOPY_COPIED) {
> > > + sioc->zero_copy_fallback++;
> >
> > ...this is counting the number of MSG_ERRQUEUE items, which is not
> > the same as the number of IO requests. That's why we only used it
> > as a boolean marker originally, rather than making it a counter.
>
> Would the logic still work and better than before? Say, it's a counter of
> "messages" rather than "IOs" then.
IIUC it is a counter of processing notifications which is not directly
correlated to any action by QEMU - neither bytes nor syscalls.
> The problem with the old code was we may report fallback=0 even if there
> can have fallback happened, as we mask that fact as long as one zerocopy
> happened in the whole batch between two flushes. So it seems this (even if
> the counter is not per-IO) is still better.
Better for what purpose though ?
If we enabled zero-copy, it is useful to know if /something/ managed
to benefit from zero-copy. ie if /always/ fails to zero-copy then
we can diagnose that the NIC driver isn't capable of it, or there
is some other limitation. If something manages to zero-copy, then
we know the feature is functionally working.
What will we do with a count of notificaitons ?
With regards,
Daniel
--
|: https://berrange.com ~~ https://hachyderm.io/@berrange :|
|: https://libvirt.org ~~ https://entangle-photo.org :|
|: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
