From: Richard Gobert <richardbgobert@gmail.com>
To: davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, yoshfuji@linux-ipv6.org, dsahern@kernel.org,
steffen.klassert@secunet.com, lixiaoyan@google.com,
alexanderduyck@fb.com, leon@kernel.org, ye.xingchen@zte.com.cn,
iwienand@redhat.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: [PATCH 0/2] gro: optimise redundant parsing of packets
Date: Mon, 30 Jan 2023 14:00:55 +0100 [thread overview]
Message-ID: <20230130130047.GA7913@debian> (raw)
Currently, the IPv6 extension headers are parsed twice: first in
ipv6_gro_receive, and then again in ipv6_gro_complete.
The field NAPI_GRO_CB(skb)->proto is used by GRO to hold the layer 4
protocol type that comes after the IPv6 layer. I noticed that it is set
in ipv6_gro_receive, but isn't used anywhere. By using this field, and
also storing the size of the network header, we can avoid parsing
extension headers a second time in ipv6_gro_complete.
The first commit frees up space in the GRO CB. The second commit reduces
the redundant parsing during the complete phase, using the freed CB
space.
I've applied this optimisation to all base protocols (IPv6, IPv4,
Ethernet). Then, I benchmarked this patch on my machine, using ftrace to
measure ipv6_gro_complete's performance, and there was an improvement.
Richard Gobert (2):
gro: decrease size of CB
gro: optimise redundant parsing of packets
include/net/gro.h | 32 +++++++++++++++++++++-----------
net/core/gro.c | 18 +++++++++++-------
net/ethernet/eth.c | 11 +++++++++--
net/ipv4/af_inet.c | 8 +++++++-
net/ipv6/ip6_offload.c | 15 ++++++++++++---
5 files changed, 60 insertions(+), 24 deletions(-)
--
2.36.1
next reply other threads:[~2023-01-30 13:01 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-30 13:00 Richard Gobert [this message]
2023-01-30 13:05 ` [PATCH 1/2] gro: decrease size of CB Richard Gobert
2023-01-30 13:07 ` [PATCH 2/2] gro: optimise redundant parsing of packets Richard Gobert
2023-01-30 15:40 ` Alexander Lobakin
2023-02-22 14:47 ` Richard Gobert
2023-01-30 17:39 ` Eric Dumazet
2023-02-22 14:35 ` Richard Gobert
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=20230130130047.GA7913@debian \
--to=richardbgobert@gmail.com \
--cc=alexanderduyck@fb.com \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=iwienand@redhat.com \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lixiaoyan@google.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=steffen.klassert@secunet.com \
--cc=ye.xingchen@zte.com.cn \
--cc=yoshfuji@linux-ipv6.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).