From: Eric Dumazet <edumazet@google.com>
To: Alexander Lobakin <alobakin@pm.me>
Cc: "David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andriin@fb.com>, Wei Wang <weiwan@google.com>,
Cong Wang <cong.wang@bytedance.com>,
Taehee Yoo <ap420073@gmail.com>, netdev <netdev@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 net-next 0/3] gro: micro-optimize dev_gro_receive()
Date: Mon, 15 Mar 2021 09:50:40 +0100 [thread overview]
Message-ID: <CANn89iKmJg641Wz7uJkcbdGd41+Vu4_eT7xtWv_V-rmyQhmyBQ@mail.gmail.com> (raw)
In-Reply-To: <20210313202946.59729-1-alobakin@pm.me>
On Sat, Mar 13, 2021 at 9:30 PM Alexander Lobakin <alobakin@pm.me> 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/20210312162127.239795-1-alobakin@pm.me
>
SGTM, thanks.
Reviewed-by: Eric Dumazet <edumaet@google.com>
prev parent reply other threads:[~2021-03-15 8:52 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-13 20:29 [PATCH v2 net-next 0/3] gro: micro-optimize dev_gro_receive() Alexander Lobakin
2021-03-13 20:30 ` [PATCH v2 net-next 1/3] gro: simplify gro_list_prepare() Alexander Lobakin
2021-03-13 20:30 ` [PATCH v2 net-next 2/3] gro: consistentify napi->gro_hash[x] access in dev_gro_receive() Alexander Lobakin
2021-03-13 20:30 ` [PATCH v2 net-next 3/3] gro: give 'hash' variable in dev_gro_receive() a less confusing name Alexander Lobakin
2021-03-15 8:50 ` Eric Dumazet [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CANn89iKmJg641Wz7uJkcbdGd41+Vu4_eT7xtWv_V-rmyQhmyBQ@mail.gmail.com \
--to=edumazet@google.com \
--cc=alobakin@pm.me \
--cc=andriin@fb.com \
--cc=ap420073@gmail.com \
--cc=ast@kernel.org \
--cc=cong.wang@bytedance.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=weiwan@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.