On 02/04/2018 6:19 PM, Eric Dumazet wrote:
On 04/02/2018 08:00 AM, Eran Ben Elisha wrote:
Seems good, but why isn't this handled directly in GRO native layer ?
ip6_tunnel and ip6_gre do not share initialization flow functions (unlike ipv4).
Changing the ipv6 init infrastructure should not be part of this
patch. we prefer to keep this one minimal, simple and safe.
Looking at gre_gro_receive() and gre_gro_complete() I could not see why they
could not be copied/pasted to IPv6.
These functions to handle GRO over GRE are already assigned in
gre_offload_init() (in net/ipv4/gre_offload.c under CONFIG_IPV6).
However without initializing the gro_cells, the receive path will not
go via napi_gro_receive path, but directly to netif_rx.
So AFAIU, only gcells->cells was missing for gro_cells_receive to
really go via GRO flow.
Maybe give more details on the changelog, it is really not obvious.
Hopefully the above filled this request.
Not really :/
So you're referring to native interface. We thought you meant native IP
module.
gro_cells_receive() is not really useful with native GRO, since packet is
already
a GRO packet by the time it reaches ip_tunnel_rcv() or __ip6_tnl_rcv()
Right. If GRO on native interface is ON, our patch doesn't help much.
The case we improve here is:
Native has GRO OFF, GRE has GRO ON.
Before this patch there were no GRO packets at all in this case, only
MTU packets went up the stack.
Sure, it might be usefull if native GRO (happening on eth0 if you prefer) did
not
handle a particular encapsulation.
Or it is turned OFF.
gro_cell was a work around before we extended GRO to be able to decap some
tunnel headers.
It seems we have to extend this to also support GRE6.
