From mboxrd@z Thu Jan 1 00:00:00 1970 From: Willem de Bruijn Subject: Re: regression: UFO removal breaks kvm live migration Date: Fri, 10 Nov 2017 14:32:29 +0900 Message-ID: References: <446b71fc-6ffc-2bb0-bae1-69424805de91@redhat.com> <20171108.203231.310648804772108001.davem@davemloft.net> <360943ad-2882-dda4-fb68-fd94f78dbfff@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Cc: David Miller , Michal Kubecek , Network Development , "Michael S. Tsirkin" , Vlad Yasevic , Paolo Bonzini To: Jason Wang Return-path: Received: from mail-oi0-f54.google.com ([209.85.218.54]:43638 "EHLO mail-oi0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750861AbdKJFdL (ORCPT ); Fri, 10 Nov 2017 00:33:11 -0500 Received: by mail-oi0-f54.google.com with SMTP id c77so6102965oig.0 for ; Thu, 09 Nov 2017 21:33:10 -0800 (PST) In-Reply-To: <360943ad-2882-dda4-fb68-fd94f78dbfff@redhat.com> Sender: netdev-owner@vger.kernel.org List-ID: On Wed, Nov 8, 2017 at 9:53 PM, Jason Wang wrote: > > > On 2017=E5=B9=B411=E6=9C=8808=E6=97=A5 20:32, David Miller wrote: >> >> From: Jason Wang >> Date: Wed, 8 Nov 2017 17:25:48 +0900 >> >>> On 2017=E5=B9=B411=E6=9C=8808=E6=97=A5 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 stil= l > 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/