On 2017年11月08日 17:08, Willem de Bruijn wrote:
On Wed, Nov 8, 2017 at 4:49 PM, Jason Wang <jasow...@redhat.com> wrote:
On 2017年11月08日 15:26, David Miller wrote:
From: Willem de Bruijn <willemdebruijn.ker...@gmail.com>
Date: Wed, 8 Nov 2017 12:36:26 +0900
On Tue, Nov 7, 2017 at 5:02 PM, Michal Kubecek <mkube...@suse.cz> 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/
