Re: GSO with udp_tunnel_xmit_skb

["Jason A. Donenfeld" <Jason@zx2c4.com>]

On Mon, Nov 9, 2015 at 2:40 AM, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> You're right.  I don't think the ordering matters.

Cool, so we're on the same page then.

In that case, any ideas about constructing UDP super-packets for GSO?
As Maciej pointed out, UFO is actually just IP fragmentation and UDP
checksums, but doesn't actually add on new UDP headers as we'd wish.
But I was digging a bit deeper and I found this gem:
skb_udp_tunnel_segment. This is the segmentation function called for
SKB_GSO_UDP_TUNNEL. For this, it does something sort of neat.

If the skb's inner_protocol_type is ENCAP_TYPE_IPPROTO, then it looks
up an "gso_inner_segment" function based on the skb->inner_ipproto
field. The lookup happens on a list of functions (called
inet6_offloads and inet_offloads) that has some nice setter/getter
methods for various modules to call.

Once it figures out which gso_inner_segment to use, it calls
__skb_udp_tunnel_segment with it, which then does some curious header
calculations on various lengths (that I need to read carefully), and
then proceeds to split the segments using our gso_inner_segment
function of choice, and then adds the length and checksum header
fields. Unfortunately, it doesn't add the UDP source and destination
port header fields. That means I might as well be building the UDP
headers ahead of time myself, which is a bit of a bummer.

Anyway, the idea would be to [ab]use SKB_GSO_UDP_TUNNEL with a
scintillating gso_inner_segment function for a custom inner_ipproto
field, in order to make a superpacket.

How's this looking as a strategy (and an outline of the "niggly bits"
as you put it)?

Jason