[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAF=yD-+yXGwMc2iUZ0avGpuAABrc1vAixasqivaMV3G44cwUrw@mail.gmail.com>
Date: Fri, 17 Nov 2017 18:00:02 -0500
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Jason Wang <jasowang@...hat.com>
Cc: David Miller <davem@...emloft.net>,
Michal Kubecek <mkubecek@...e.cz>,
Network Development <netdev@...r.kernel.org>,
"Michael S. Tsirkin" <mst@...hat.com>,
Vlad Yasevic <vyasevic@...hat.com>,
Paolo Bonzini <pbonzini@...hat.com>
Subject: Re: regression: UFO removal breaks kvm live migration
On Fri, Nov 17, 2017 at 9:48 AM, Willem de Bruijn
<willemdebruijn.kernel@...il.com> wrote:
>>> 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).
>>
>> I'm finishing up and running some tests. The majority of the patch is a
>> straightforward partial revert of the patchset, so while fairly large for a
>> patch to net (~150 lines, esp. in udp[46]_ufo_fragment), that is all
>> thoroughly tested code. Notably absent are the protocol layer and
>> hardware support (NETIF_F_UFO) portions.
>>
>> The only open issue is whether to rely on existing skb_gso_segment
>> processing in the transmit path from validate_xmit_skb or to add new
>> skb_gso_segment calls directly to tun_get_user, tap_get_user and
>> pf_packet. Tun has to loop around four different ways of injecting
>> packets into the device. Something like the below snippet.
>>
>> More conservative is to introduce no completely new code and rely on
>> validate_xmit_skb, but that means having to protect the entire stack
>> against skbs with SKB_GSO_UDP, so also bringing back some
>> checksum and fragment handling snippets in gre_gso_segment,
>> __skb_udp_tunnel_segment, act_csum and openvswitch.
>
> Come to think of it, as this patch does not bring back NETIF_F_UFO
> support to NETIF_F_GSO_SOFTWARE, the tunnel cases can be
> excluded.
>
> Then this is probably the simpler and more obviously correct approach.
Sent: http://patchwork.ozlabs.org/patch/839168/
Powered by blists - more mailing lists