Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752840AbbKIDSO (ORCPT ); Sun, 8 Nov 2015 22:18:14 -0500 Received: from mail-lf0-f54.google.com ([209.85.215.54]:33152 "EHLO mail-lf0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752108AbbKIDSL (ORCPT ); Sun, 8 Nov 2015 22:18:11 -0500 MIME-Version: 1.0 In-Reply-To: References: <20151108105710.GA30282@gondor.apana.org.au> <20151109014045.GA1358@gondor.apana.org.au> Date: Sun, 8 Nov 2015 19:18:08 -0800 Message-ID: Subject: Re: GSO with udp_tunnel_xmit_skb From: =?UTF-8?Q?Maciej_=C5=BBenczykowski?= To: "Jason A. Donenfeld" Cc: Herbert Xu , Tom Herbert , Jiri Benc , Netdev , LKML Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2007 Lines: 44 > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/