Re: regression: UFO removal breaks kvm live migration

From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Jason Wang <jasowang@redhat.com>
Cc: David Miller <davem@davemloft.net>,
	Michal Kubecek <mkubecek@suse.cz>,
	Network Development <netdev@vger.kernel.org>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Vlad Yasevic <vyasevic@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: regression: UFO removal breaks kvm live migration
Date: Fri, 10 Nov 2017 14:32:29 +0900	[thread overview]
Message-ID: <CAF=yD-J3+YJgxEYmaFRgk2QFfYLyu7fKDCm=qkrVo9qBXRHoTA@mail.gmail.com> (raw)
In-Reply-To: <360943ad-2882-dda4-fb68-fd94f78dbfff@redhat.com>

On Wed, Nov 8, 2017 at 9:53 PM, Jason Wang <jasowang@redhat.com> wrote:
>
>
> On 2017年11月08日 20:32, David Miller wrote:
>>
>> From: Jason Wang <jasowang@redhat.com>
>> Date: Wed, 8 Nov 2017 17:25:48 +0900
>>
>>> On 2017年11月08日 17:08, Willem de Bruijn wrote:
>>>>
>>>> That won't help in the short term. I'm still reading up to see if
>>>> there are
>>>> any other options besides reimplement or advertise-but-drop, such as
>>>> an implicit trigger that would make the guest renegotiate. It's
>>>> unlikely, but
>>>> worth a look..
>>>
>>> Yes, this looks hard. And even if we can manage to do this, it looks
>>> an overkill since it will impact all guest after migration.
>>
>> Like Willem I would much prefer "advertise-but-drop" if it works.
>
>
> This makes migration work but all guest UFO traffic will stall.
>
>>
>> In the long term feature renegotiation triggers are a must.
>>
>> There is no way for us to remove features otherwise.
>
>
> We can remove if we don't break userspace(guest).
>
>> In my opinion
>> this will even make migrations more powerful.
>
>
> But this does not help for guest running old version of kernel which still
> think UFO work.

Indeed, if we have to support live migration of arbitrary old guests
without any expectations on hypervisor version either, features can
simply never be reverted, even if a negotiation interface exists.

At least for upcoming features and devices, guest code should not
have this expectation, but from the start allow renegation such as
CTRL_GUEST_OFFLOADS [1] based on a host trigger. But for
tuntap TUNSETOFFLOAD it seems that ship has sailed.

Okay, I will send a patch to reinstate UFO for this use case (only). There
is some related work in tap_handle_frame and packet_direct_xmit to
segment directly in the device. I will be traveling the next few days, so
it won't be in time for 4.14 (but can go in stable later, of course).

[1] https://patchwork.kernel.org/patch/9850785/