Re: [PATCH net-next 1/3] net: gro: set {inner_,}network_header in receive phase

Eric Dumazet wrote: > On Thu, Feb 29, 2024 at 2:22 PM Richard Gobert > wrote: >> >> >> >> Eric Dumazet wrote: >>> >>> My intuition is that this patch has a high cost for normal GRO processing. >>> SW-GRO is already a bottleneck on ARM cores in smart NICS. >>> >>> I would suggest instead using

Re: [PATCH net-next 1/3] net: gro: set {inner_,}network_header in receive phase

On Thu, Feb 29, 2024 at 2:22 PM Richard Gobert wrote: > > > > Eric Dumazet wrote: > > > > My intuition is that this patch has a high cost for normal GRO processing. > > SW-GRO is already a bottleneck on ARM cores in smart NICS. > > > > I would suggest instead using parameters to give both the nhof

Re: [PATCH net-next 1/3] net: gro: set {inner_,}network_header in receive phase

Eric Dumazet wrote: > > My intuition is that this patch has a high cost for normal GRO processing. > SW-GRO is already a bottleneck on ARM cores in smart NICS. > > I would suggest instead using parameters to give both the nhoff and thoff > values > this would avoid many conditionals in the fa

Re: [PATCH net-next 1/3] net: gro: set {inner_,}network_header in receive phase

On Thu, Feb 22, 2024 at 10:05 PM Richard Gobert wrote: > > Commits a602456 ("udp: Add GRO functions to UDP socket") and 57c67ff ("udp: > additional GRO support") introduce incorrect usage of {ip,ipv6}_hdr in the > complete phase of gro. The functions always return skb->network_header, > which in t

[PATCH net-next 1/3] net: gro: set {inner_,}network_header in receive phase

Commits a602456 ("udp: Add GRO functions to UDP socket") and 57c67ff ("udp: additional GRO support") introduce incorrect usage of {ip,ipv6}_hdr in the complete phase of gro. The functions always return skb->network_header, which in the case of encapsulated packets at the gro complete phase, is alwa