Willem de Bruijn wrote:
Richard Gobert wrote:
Eric Dumazet wrote:
On Sat, Mar 9, 2024 at 4:35 PM Richard Gobert richardbgobert@gmail.com wrote:
{inet,ipv6}_gro_receive functions perform flush checks (ttl, flags, iph->id, ...) against all packets in a loop. These flush checks are relevant only to tcp flows, and as such they're used to determine whether the packets can be merged later in tcp_gro_receive.
These checks are not relevant to UDP packets.
I do not think this claim is true.
Incoming packets -> GRO -> GSO -> forwarded packets
The {GRO,GSO} step must be transparent, GRO is not LRO.
Sorry, I should rephrase myself. The patch preserves the current logic in GRO. These L3 checks (ttl, flags, etc.) are written to NAPI_GRO_CB(p)->{flush,flush_id}, and NAPI_GRO_CB(skb)->is_atomic - and all of these are currently used only in tcp_gro_receive.
That was perhaps an oversight when adding UDP GRO?
Simply because the flush is determined in the innermost callback.
It might have been an oversight. From what I have seen it's only relevant to GRO's UDP fraglist path (it was added in 9fd1ff5d ("udp: Support UDP fraglist GRO/GSO.")). That's the only UDP path that calls skb_gro_receive - which may alter the forwarded packets and make GRO/GSO not transparent.
AFAIU NAPI_GRO_CB(p)->flush value is not overwritten in encapsulation - it is determined by both outer and inner callbacks.
I tried to preserve the current behaviour in GRO - if we want to change this behaviour I'll gladly do it, although I'd prefer to address it in a different patch series. What do you think?
Thanks