From: Paolo Abeni <pabeni@redhat.com>
To: Felix Fietkau <nbd@nbd.name>,
netdev@vger.kernel.org, Eric Dumazet <edumazet@google.com>,
"David S. Miller" <davem@davemloft.net>,
David Ahern <dsahern@kernel.org>,
Jakub Kicinski <kuba@kernel.org>
Cc: willemdebruijn.kernel@gmail.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 net-next v4 6/6] net: add heuristic for enabling TCP fraglist GRO
Date: Tue, 30 Apr 2024 12:12:56 +0200 [thread overview]
Message-ID: <e590ba4608c9810d3d75fefdcbba9f2a02c23a0f.camel@redhat.com> (raw)
In-Reply-To: <20240427182305.24461-7-nbd@nbd.name>
On Sat, 2024-04-27 at 20:23 +0200, Felix Fietkau wrote:
> When forwarding TCP after GRO, software segmentation is very expensive,
> especially when the checksum needs to be recalculated.
> One case where that's currently unavoidable is when routing packets over
> PPPoE. Performance improves significantly when using fraglist GRO
> implemented in the same way as for UDP.
>
> When NETIF_F_GRO_FRAGLIST is enabled, perform a lookup for an established
> socket in the same netns as the receiving device. While this may not
> cover all relevant use cases in multi-netns configurations, it should be
> good enough for most configurations that need this.
>
> Here's a measurement of running 2 TCP streams through a MediaTek MT7622
> device (2-core Cortex-A53), which runs NAT with flow offload enabled from
> one ethernet port to PPPoE on another ethernet port + cake qdisc set to
> 1Gbps.
>
> rx-gro-list off: 630 Mbit/s, CPU 35% idle
> rx-gro-list on: 770 Mbit/s, CPU 40% idle
>
> Signe-off-by: Felix Fietkau <nbd@nbd.name>
> ---
> net/ipv4/tcp_offload.c | 32 ++++++++++++++++++++++++++++++++
> net/ipv6/tcpv6_offload.c | 35 +++++++++++++++++++++++++++++++++++
> 2 files changed, 67 insertions(+)
>
> diff --git a/net/ipv4/tcp_offload.c b/net/ipv4/tcp_offload.c
> index 87ae9808e260..3e9b8c6f9c8c 100644
> --- a/net/ipv4/tcp_offload.c
> +++ b/net/ipv4/tcp_offload.c
> @@ -407,6 +407,36 @@ void tcp_gro_complete(struct sk_buff *skb)
> }
> EXPORT_SYMBOL(tcp_gro_complete);
>
> +static void tcp4_check_fraglist_gro(struct list_head *head, struct sk_buff *skb,
> + struct tcphdr *th)
> +{
> + const struct iphdr *iph;
> + struct sk_buff *p;
> + struct sock *sk;
> + struct net *net;
> + int iif, sdif;
> +
> + if (!(skb->dev->features & NETIF_F_GRO_FRAGLIST))
Should we add an 'unlikely()' here to pair with unlikely(is_flist) in
*gro_receive / *gro_complete?
Should this test be moved into the caller, to avoid an unconditional
function call in the ipv6 code?
(Also waiting for explicit ack from Eric)
Thank,
Paolo
next prev parent reply other threads:[~2024-04-30 10:13 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20240427182305.24461-1-nbd@nbd.name>
2024-04-27 18:22 ` [PATCH v4 net-next v4 1/6] net: move skb_gro_receive_list from udp to core Felix Fietkau
2024-04-27 18:22 ` [PATCH v4 net-next v4 2/6] net: add support for segmenting TCP fraglist GSO packets Felix Fietkau
2024-04-30 10:19 ` Paolo Abeni
2024-04-30 10:27 ` Felix Fietkau
2024-04-30 10:40 ` Paolo Abeni
2024-04-30 10:57 ` Felix Fietkau
2024-04-30 10:23 ` Paolo Abeni
2024-04-30 11:31 ` Eric Dumazet
2024-04-27 18:22 ` [PATCH v4 net-next v4 3/6] net: add code for TCP fraglist GRO Felix Fietkau
2024-04-27 18:23 ` [PATCH v4 net-next v4 4/6] net: create tcp_gro_lookup helper function Felix Fietkau
2024-04-27 18:23 ` [PATCH v4 net-next v4 5/6] net: create tcp_gro_header_pull " Felix Fietkau
2024-04-27 18:23 ` [PATCH v4 net-next v4 6/6] net: add heuristic for enabling TCP fraglist GRO Felix Fietkau
2024-04-30 3:25 ` Jakub Kicinski
2024-04-30 10:12 ` Paolo Abeni [this message]
2024-04-30 10:23 ` Felix Fietkau
2024-04-30 10:31 ` Paolo Abeni
2024-04-30 10:55 ` Felix Fietkau
2024-04-30 11:14 ` Paolo Abeni
2024-04-30 10:33 ` Eric Dumazet
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=e590ba4608c9810d3d75fefdcbba9f2a02c23a0f.camel@redhat.com \
--to=pabeni@redhat.com \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nbd@nbd.name \
--cc=netdev@vger.kernel.org \
--cc=willemdebruijn.kernel@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®