On Mon, Jan 14, 2019 at 12:09:22PM -0500, Willem de Bruijn wrote:

On Mon, Jan 14, 2019 at 7:50 AM Steffen Klassert
[off-list ref] wrote:

quoted

On Sun, Dec 23, 2018 at 08:15:40PM -0500, Willem de Bruijn wrote:

quoted

I would prefer to split the patch that adds UDP GRO on the forwarding
path into one that enables it for existing GRO (the hack you refer to
above) and a second one to optionally convert to listified processing.

The hack was to skip the socket lookup. While that was ok for a
forwarding test, it will affect the local receive path of course.

Currently, I check if there is a GRO capable socket. If yes,
do standard GRO. If no, do listified GRO regardless if packets
are going to be forwarded or locally received. So UDP GRO is
always on with this.

I understand. What I suggest is to split into two: enable GRO on the
forwarding path independently from converting the method to listified
GRO.

Ok, will do that in the next patchset.

quoted

We would need to do an early route lookup to check if the packets
are going to be forwarded or locally received. The current patchset
does not implement this, but could be done. Maybe doing a route
lookup based on some static key that will be enabled when forwarding
on the receiving device is enabled.

But even if the route lookup tell us that the packet should go the
forwarding path, netfilter (bpfilter?) could reroute the packet.
If we do an early route lookup, it would be good to have some early
netfilter (bpfilter?) too, so that we can know which path the packets
go. In this case we could do listified GRO even for TCP, if we can
know that we have to do software segmentation later on.

Btw. do we already have hardware that can do UDP LSO?

Yes, mlx5

I don't think that the route lookup is needed. If listified is cheaper
for local delivery, too, then we can make that the default unless a
device is active with h/w offload and ip forwarding is enabled. If it
isn't, then use it iff ip forwarding is enabled. I think it's fine to
mispredict between the two in edge cases with netfilter mangling, as
long as all paths can correctly handle both types of GRO packets.

I'd need at least a route lookup for my usecase, because listified
GRO is always cheaper when a xfrm transformation is needed (even for
TCP). In this case is software GSO needed. So I'd need to either have
an early route lookup or maybe some early ingress hook where a route
lookup could be imlemented in.

quoted

quoted

For both existing UDP GRO and listified, we should verify that this is
not a potential DoS vector before enabling by default.

Yes, but should'nt this be the same as with TCP GRO?

That is by now well-tested. I don't think we can simply assume
equivalence for UDP, also because that is easier to spoof.

What would be a good test for this? I played with masscan
and hping3, but did not notice any differences between
net-next and net-next + UDP GRO patches.