All of lore.kernel.org
 help / color / mirror / Atom feed
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Jason Wang <jasowang@redhat.com>
Cc: David Miller <davem@davemloft.net>,
	Michal Kubecek <mkubecek@suse.cz>,
	Network Development <netdev@vger.kernel.org>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Vlad Yasevic <vyasevic@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: regression: UFO removal breaks kvm live migration
Date: Fri, 17 Nov 2017 18:00:02 -0500	[thread overview]
Message-ID: <CAF=yD-+yXGwMc2iUZ0avGpuAABrc1vAixasqivaMV3G44cwUrw@mail.gmail.com> (raw)
In-Reply-To: <CAF=yD-KuNn+U6Cwecx7NUZzuL9V5HKC=gr2oqcrSRYJw7N_bSQ@mail.gmail.com>

On Fri, Nov 17, 2017 at 9:48 AM, Willem de Bruijn
<willemdebruijn.kernel@gmail.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/

  reply	other threads:[~2017-11-17 23:00 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-07  8:02 regression: UFO removal breaks kvm live migration Michal Kubecek
2017-11-08  3:36 ` Willem de Bruijn
2017-11-08  6:26   ` David Miller
2017-11-08  7:49     ` Jason Wang
2017-11-08  8:08       ` Willem de Bruijn
2017-11-08  8:25         ` Jason Wang
2017-11-08 11:32           ` David Miller
2017-11-08 12:53             ` Jason Wang
2017-11-08 12:58               ` David Miller
2017-11-10  5:32               ` Willem de Bruijn
2017-11-10  5:59                 ` David Miller
2017-11-17 14:31                 ` Willem de Bruijn
2017-11-17 14:48                   ` Willem de Bruijn
2017-11-17 23:00                     ` Willem de Bruijn [this message]
2017-11-08 16:01             ` Michael S. Tsirkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAF=yD-+yXGwMc2iUZ0avGpuAABrc1vAixasqivaMV3G44cwUrw@mail.gmail.com' \
    --to=willemdebruijn.kernel@gmail.com \
    --cc=davem@davemloft.net \
    --cc=jasowang@redhat.com \
    --cc=mkubecek@suse.cz \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=vyasevic@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.