On Mon, Nov 9, 2015 at 2:40 AM, Herbert Xu <herb...@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 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html