From mboxrd@z Thu Jan 1 00:00:00 1970 From: Willem de Bruijn Subject: Re: regression: UFO removal breaks kvm live migration Date: Wed, 8 Nov 2017 17:08:35 +0900 Message-ID: References: <20171107080224.v6z65jvimpa5ohs4@unicorn.suse.cz> <20171108.152624.282888162096095926.davem@davemloft.net> 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 To: Jason Wang Return-path: Received: from mail-ot0-f177.google.com ([74.125.82.177]:52185 "EHLO mail-ot0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750727AbdKHIJQ (ORCPT ); Wed, 8 Nov 2017 03:09:16 -0500 Received: by mail-ot0-f177.google.com with SMTP id n74so1600980ota.8 for ; Wed, 08 Nov 2017 00:09:16 -0800 (PST) In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On Wed, Nov 8, 2017 at 4:49 PM, Jason Wang wrote: > > > On 2017=E5=B9=B411=E6=9C=8808=E6=97=A5 15:26, David Miller wrote: >> >> From: Willem de Bruijn >> Date: Wed, 8 Nov 2017 12:36:26 +0900 >> >>> On Tue, Nov 7, 2017 at 5:02 PM, Michal Kubecek wrote= : >>>> >>>> I didn't have time to think it through yet but perhaps we could allow >>>> setting TUN_F_UFO and ignore its value. >>> >>> If the feature is enabled guests may try to send UFO packets, which >>> the host is no longer able to fragment. >>> >>> virtio_net_hdr_to_skb will drop the packets immediately based on >>> gso_type and tun_get_user will return EINVAL. >>> >>> Still, perhaps that's preferable as migration will succeed and most >>> guests won't ever try to send those packets in the first place. >> >> However, this would create the situation where there is no way >> to properly probe for the actual presence of UFO support. > > > I think we should not have any assumption on how guest will use the featu= re. > So I could not come a better than bring it back partially for TAP, looks > like we only need segment them in tun_get_user(). Live migration essentially expects that features can never be removed [1], as feature bits are not renegotiated after migration. In the short term we'= ll have to work around that, but in the long term that does not seem practical= . There already exist interfaces to renegotiate guest/host state at runtime, including for offloads [2][3]. For newer guests, we should support a trigge= r from the host to renegotiate offloads. 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, b= ut worth a look.. [1] https://lists.linuxfoundation.org/pipermail/virtualization/2014-Novembe= r/028126.html [2] https://lists.linuxfoundation.org/pipermail/virtualization/2013-April/0= 23818.html [3] https://patchwork.kernel.org/patch/9850785/