netdev - Re: [RFC] net: add gro frag support to udp tunnel api

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 30 Jan 2020 11:16:18 +0100
From:   Steffen Klassert <steffen.klassert@...unet.com>
To:     "Jason A. Donenfeld" <Jason@...c4.com>
CC:     <netdev@...r.kernel.org>
Subject: Re: [RFC] net: add gro frag support to udp tunnel api

Hi Jason,

On Mon, Jan 27, 2020 at 04:24:11PM +0100, Jason A. Donenfeld wrote:
> Hi Steffen,
> 
> This is very much a "RFC", in that the code here is fodder for
> discussion more than something I'm seriously proposing at the moment.
> I'm writing to you specifically because I recall us having discussed
> something like this a while ago and you being interested.
> 
> WireGuard would benefit from getting lists of SKBs all together in a
> bunch on the receive side. At the moment, encap_rcv splits them apart
> one by one before giving them to the API. This patch proposes a way to
> opt-in to receiving them before they've been split. The solution
> involves adding an encap_type flag that enables calling the encap_rcv
> function earlier before the skbs have been split apart.
> 
> I worry that it's not this straight forward, however, because of this
> function below called, "udp_unexpected_gso". It looks like there's a
> fast path for the case when it doesn't need to be split apart, and that
> if it is already split apart, that's expected, whereas splitting it
> apart would be "unexpected." I'm not too familiar with this code. Do you
> know off hand why this would be unexpected? And does that imply that a
> proper implementation of this might be a bit more involved? Or is the
> naming just silly and this actually is _the_ path where this happens?
> 
> The other thing I'm wondering with regards to this is how you even hit
> this path. So far I've only been able to hit it with the out of tree
> Qualcom driver, "rmnet_perf". I saw a mailing list discussion a few
> years ago about adding some flags to be able to simulate this with veth,
> but I didn't see that go anywhere. Figuring out how I can test this is
> probably a good idea before proceeding further.
> 
> Finally, and most importantly, is this overlapping with something you're
> working on at the moment? Where do you stand with this? Did you wind up
> solving your own use cases in a different way, or are you sitting on a
> more proper version of this RFC or something else?

I have a patch to enable GRO for ESP in UDP encapsulation.
The patch is not that well tested so far, so I hold it back
for now. But I think it won't overlap with enabling fraglist
GRO for encap sockets. I have not thought about enabling
fraglist GRO for encap sockets, but a flag to signal this
could be a way to go.

Other that that I plan to enable UDP GRO by default
once we are sure that this won't add a regression.