Re: [PATCH v2 4/4] virtio-net: Add support for USO features
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