Re: GSO with udp_tunnel_xmit_skb

["Maciej Żenczykowski" <zenczykowski@gmail.com>]

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

I'm guessing the udp src dst port (and ??possibly?? optional gue
headers) are meant to be part of the external headers that are already
pre-populated.

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

That's probably basically what that was designed for.  So doesn't seem
like an abuse.

Tunnel GSO offloads are still very very fresh and actively being
worked on (by Tom and Eric among others).
I'm afraid my knowledge of them at HEAD is very limited.
I've only recently started experimenting in this area myself.

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

Looks fine.  Devil is in the details.  You may discover that the stack
is still missing some things you'll need to add in.

(for example, personally I'm trying to understand if CHECKSUM_PARTIAL
shouldn't carry an extra bit of information specifying whether
we need a TCP or UDP style checksum, since they differ in how a
checksum of 0 is transmitted, it appears this causes nic drivers
to need to redigest the packet to figure it out before they can pass
it on to the hardware)

- Maciej