[v2,net-next,0/3] gro: micro-optimize dev_gro_receive()

Message

Alexander Lobakin March 13, 2021, 8:29 p.m. UTC

This random series addresses some of suboptimal constructions used
in the main GRO entry point.
The main body is gro_list_prepare() simplification and pointer usage
optimization in dev_gro_receive() itself. Being mostly cosmetic, it
gives like +10 Mbps on my setup to both TCP and UDP (both single- and
multi-flow).

Since v1 [0]:
 - drop the replacement of bucket index calculation with
   reciprocal_scale() since it makes absolutely no sense (Eric);
 - improve stack usage in dev_gro_receive() (Eric);
 - reverse the order of patches to avoid changes superseding.

[0] https://lore.kernel.org/netdev/[e-mail]

Alexander Lobakin (3):
  gro: simplify gro_list_prepare()
  gro: consistentify napi->gro_hash[x] access in dev_gro_receive()
  gro: give 'hash' variable in dev_gro_receive() a less confusing name

 net/core/dev.c | 40 ++++++++++++++++++----------------------
 1 file changed, 18 insertions(+), 22 deletions(-)

--
2.30.2

Comments

Eric Dumazet March 15, 2021, 8:50 a.m. UTC | #1

On Sat, Mar 13, 2021 at 9:30 PM Alexander Lobakin <[e-mail]> wrote:
>
> This random series addresses some of suboptimal constructions used
> in the main GRO entry point.
> The main body is gro_list_prepare() simplification and pointer usage
> optimization in dev_gro_receive() itself. Being mostly cosmetic, it
> gives like +10 Mbps on my setup to both TCP and UDP (both single- and
> multi-flow).
>
> Since v1 [0]:
>  - drop the replacement of bucket index calculation with
>    reciprocal_scale() since it makes absolutely no sense (Eric);
>  - improve stack usage in dev_gro_receive() (Eric);
>  - reverse the order of patches to avoid changes superseding.
>
> [0] https://lore.kernel.org/netdev/[e-mail]
>

SGTM, thanks.

Reviewed-by: Eric Dumazet <[e-mail]>