On Wed, Nov 8, 2017 at 9:53 PM, Jason Wang <jasow...@redhat.com> wrote: > > > On 2017年11月08日 20:32, David Miller wrote: >> >> From: Jason Wang <jasow...@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/
