Re: [PATCH v2 4/4] virtio-net: Add support for USO features

["Michael S. Tsirkin" <mst@redhat.com>]

On Mon, Aug 05, 2024 at 04:53:52PM +0900, Akihiko Odaki wrote:
> On 2024/08/05 16:30, Michael S. Tsirkin wrote:
> > On Sun, Aug 04, 2024 at 03:49:45PM +0900, Akihiko Odaki wrote:
> > > I suggest disabling all offload features of virtio-net with 9.2.
> > 
> > Yea ... no.
> > 
> > > I want to keep things consistent so I want to disable all at once. This
> > > change will be very uncomfortable for us, who are implementing offload
> > > features, but I hope it will motivate us to implement a proper solution.
> > 
> > It's uncomfortable for users.
> 
> An obvious alternative is to set cross-migrate=off by default (I dropped the
> no- prefix because no-cross-migrate=off is confusing). I don't have a
> particular idea whether cross-migrate should be on or off by default.
> 
> This is a trade-off of safety and performance. In general, I believe safety
> should come first before performance.

There's no actual safety issue here. You can't migrate certain configurations.
So I don't really understand what "cross-migrate" is supposed to do:
fail migration in 100% of cases?

I can see value in getting configuration from source and not starting
qemu on destination if it can not be migrated. This is rather
straight-forward, and seems directly useful for management.
I also see value in getting configuration from destination and starting
on source only if it can be migrated. As a variant of last one, I maybe
see value in getting that info from multiple destinations. Using this
last kind of thing would be trickier because it's not at the libvirt level,
so we would need very good documentation.

> On the other hand, disabling offload features is a breaking change. QEMU
> also has -only-migratable option; it is more consistent to make the
> additional assurance for migration opt-in instead of opt-out. Finally, I see
> migration across hosts as an advanced feature, and perhaps it can be
> justified to make it more like an optional feature.
> 
> Regards,
> Akihiko Odaki

It's already an optional feature.

-- 
MST