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

[Peter Xu <peterx@redhat.com>]

On Tue, Mar 11, 2025 at 08:13:16AM +0000, Daniel P. Berrangé wrote:
> On Mon, Mar 10, 2025 at 04:03:26PM -0400, Peter Xu wrote:
> > On Mon, Mar 10, 2025 at 07:48:16PM +0000, Daniel P. Berrangé wrote:
> > > 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.
> > 
> > :-(
> > 
> > We could potentially mark MigrationStats to be experimental as a whole and
> > declare that in deprecate.rst too, then after two releases, we can randomly
> > add / remove fields as wish without always need to go through the
> > deprecation process, am I right?
> 
> IMHO that would be an abuse of the process and harmful to applications
> and users consuming stats.

Ah I just noticed that's the exact same one we included in
query-migrate.. Then yes, the stable ABI is important here.

So for this specific case, maybe we shouldn't have exposed it in QMP from
the start.

To me, it's a question on whether we could have something experimental and
be exposed to QMP, where we don't need to guarantee a strict stable ABI, or
a very loose ABI (e.g. we can guarantee the command exists, and with
key-value string-integer pairs, nothing else).

Taking the example of downtime reports: there used to be attempts on the
list capturing details of downtime measurements for each migration and
report that via QMP, probably via the stats.  At that time, I was concerned
that whatever we change alone the lines then we risk breaking the ABI
(e.g. we move code within blackout path and it can move contribution of X
from bucket B1 to B2).  At that time the work was not merged.

However, such things (either downtime reports, or some of the stats that
are pretty much not designed for generic users, like this zerocopy success
counter) would still be nice if we can collect them in QMP queries.

Maybe what we need is a new MigrationInfoOptional, to be embeded into
MigrationInfo (or not), marked experimental.  Then in the future whenever
we want to add some new statistics, we could decide whether it should be
part of stable ABI or not.

PS: we have Juraj actively looking at selftests to measure downtime
contributions of live migrations.  Currently we need to leverage
tracepoints and parse the results.  If that sounds reasonable, we could
start with having MigrationInfoOptional and export downtime metrics.

Thanks,

-- 
Peter Xu