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, 17 Nov 2017 18:00:02 -0500 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" Cc: David Miller , Michal Kubecek , Network Development , "Michael S. Tsirkin" , Vlad Yasevic , Paolo Bonzini To: Jason Wang Return-path: Received: from mail-ot0-f177.google.com ([74.125.82.177]:37541 "EHLO mail-ot0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1423108AbdKQXAn (ORCPT ); Fri, 17 Nov 2017 18:00:43 -0500 Received: by mail-ot0-f177.google.com with SMTP id s4so3337932ote.4 for ; Fri, 17 Nov 2017 15:00:43 -0800 (PST) In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On Fri, Nov 17, 2017 at 9:48 AM, Willem de Bruijn 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/