From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Wang Subject: Re: regression: UFO removal breaks kvm live migration Date: Wed, 8 Nov 2017 17:25:48 +0900 Message-ID: <446b71fc-6ffc-2bb0-bae1-69424805de91@redhat.com> References: <20171107080224.v6z65jvimpa5ohs4@unicorn.suse.cz> <20171108.152624.282888162096095926.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Cc: David Miller , Michal Kubecek , Network Development , "Michael S. Tsirkin" , Vlad Yasevic To: Willem de Bruijn Return-path: Received: from mx1.redhat.com ([209.132.183.28]:39882 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750760AbdKHIZ4 (ORCPT ); Wed, 8 Nov 2017 03:25:56 -0500 In-Reply-To: Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 2017年11月08日 17:08, Willem de Bruijn wrote: > On Wed, Nov 8, 2017 at 4:49 PM, Jason Wang wrote: >> >> On 2017年11月08日 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 feature. >> 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 trigger > from the host to renegotiate offloads. I could not think of a real use case for this other than trying to workaround a bug. > > 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. Thanks > > [1] https://lists.linuxfoundation.org/pipermail/virtualization/2014-November/028126.html > [2] https://lists.linuxfoundation.org/pipermail/virtualization/2013-April/023818.html > [3] https://patchwork.kernel.org/patch/9850785/