On Thu, 2024-06-20 at 15:19 -0700, Yan Zhai wrote: > Software GRO is currently controlled by a single switch, i.e. > > ethtool -K dev gro on|off > > However, this is not always desired. When GRO is enabled, even if the > kernel cannot GRO certain traffic, it has to run through the GRO receive > handlers with no benefit. > > There are also scenarios that turning off GRO is a requirement. For > example, our production environment has a scenario that a TC egress hook > may add multiple encapsulation headers to forwarded skbs for load > balancing and isolation purpose. The encapsulation is implemented via > BPF. But the problem arises then: there is no way to properly offload a > double-encapsulated packet, since skb only has network_header and > inner_network_header to track one layer of encapsulation, but not two. > On the other hand, not all the traffic through this device needs double > encapsulation. But we have to turn off GRO completely for any ingress > device as a result. Could you please add more details WRT this last statement? I'm unsure if I understand your problem. My guess is as follow: Your device receive some traffic, GRO and forward it, and the multiple encapsulation can happen on such forwarded traffic (since I can't find almost none of the above your message is mainly a wild guess). Assuming I guessed correctly, I think you could solve the problem with no kernel changes: redirect the to-be-tunneled traffic to some virtual device and all TX offload on top of it and let the encap happen there. Cheers, Paolo
