Messages in this thread | | | Date | Tue, 30 Apr 2024 12:23:52 +0200 | Subject | Re: [PATCH v4 net-next v4 6/6] net: add heuristic for enabling TCP fraglist GRO | From | Felix Fietkau <> |
| |
On 30.04.24 12:12, Paolo Abeni wrote: > 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? Not sure if unlikely() will make any difference here. I think it makes more sense in the other places than here.
> Should this test be moved into the caller, to avoid an unconditional > function call in the ipv6 code?
The function is already called from tcp4_gro_receive, which is only called by IPv4 code. Also, since it's a static function called in only one place, it gets inlined by the compiler (at least in my builds). Not sure what unconditional function call you're referring to.
- Felix
| |