>> 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.
