UDP GRO without Merging

UDP GRO without Merging

[Gauvain Roussel-Tarbouriech]

Subject:

Hello Netdev,

I am working on WireGuard as part of Google Summer of Code and Jason and
I are working on adding GRO to WireGuard, on the udp_tunnel side of
things. The goal is to inform udp_tunnel’s gro_receive that certain
packets are part of the same flow. Then sometime later, we’d like to
have a list of those same-flow packets appear in gro_complete. As far as
I can tell, the API seems well suited for merging packets in
gro_receive, such that gro_complete only then gets one single merged
packet. However, we need to receive the entire list of same-flow packets
in gro_complete, unmerged. Is this possible with the present APIs?

The goal of this, by the way, is to have more efficient clumping in
multi-core packet decryption, similar to what’s done using GSO on the
send/encryption side. See Jason’s netdevconf presentation for details on
this: https://www.wireguard.com/papers/wireguard-netdev22.pdf (section
“Generic Segmentation Offload Batching”).

Thanks,
-G

Re: UDP GRO without Merging

[Steffen Klassert]

On Wed, Jul 25, 2018 at 11:53:45AM +0200, Gauvain Roussel-Tarbouriech wrote:
> Subject:
> 
> Hello Netdev,
> 
> I am working on WireGuard as part of Google Summer of Code and Jason and
> I are working on adding GRO to WireGuard, on the udp_tunnel side of
> things. The goal is to inform udp_tunnel’s gro_receive that certain
> packets are part of the same flow. Then sometime later, we’d like to
> have a list of those same-flow packets appear in gro_complete. As far as
> I can tell, the API seems well suited for merging packets in
> gro_receive, such that gro_complete only then gets one single merged
> packet. However, we need to receive the entire list of same-flow packets
> in gro_complete, unmerged. Is this possible with the present APIs?

We recently posted a patchset that does this GRO packet chaining.
Not sure if this is exactly what you need, but you can have a look here:

https://www.spinics.net/lists/netdev/msg508093.html

This is implemented as a part of a forward fastpath, but
could be also moved generic code if needed.