From: Jakub Kicinski <kuba@kernel.org>
To: Paolo Abeni <pabeni@redhat.com>
Cc: netdev@vger.kernel.org,
Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Simon Horman <horms@kernel.org>, David Ahern <dsahern@kernel.org>
Subject: Re: [PATCH net-next 0/2] udp_tunnel: GRO optimizations
Date: Thu, 6 Mar 2025 10:50:46 -0800 [thread overview]
Message-ID: <20250306105046.0aca16b3@kernel.org> (raw)
In-Reply-To: <cover.1741275846.git.pabeni@redhat.com>
On Thu, 6 Mar 2025 16:56:51 +0100 Paolo Abeni wrote:
> The UDP tunnel GRO stage is source of measurable overhead for workload
> based on UDP-encapsulated traffic: each incoming packets requires a full
> UDP socket lookup and an indirect call.
>
> In the most common setups a single UDP tunnel device is used. In such
> case we can optimize both the lookup and the indirect call.
>
> Patch 1 tracks per netns the active UDP tunnels and replaces the socket
> lookup with a single destination port comparison when possible.
>
> Patch 2 tracks the different types of UDP tunnels and replaces the
> indirect call with a static one when there is a single UDP tunnel type
> active.
>
> I measure ~5% performance improvement in TCP over UDP tunnel stream
> tests on top of this series.
Breaks the build with NET_UDP_TUNNEL=n (in contest) :(
net/ipv4/udp_offload.c: In function ‘udp_tunnel_gro_rcv’:
net/ipv4/udp_offload.c:172:16: error: returning ‘struct sk_buff *’ from a function with incompatible return type ‘struct skbuff *’ [-Werror=incompatible-pointer-types]
172 | return call_gro_receive_sk(udp_sk(sk)->gro_receive, sk, head, skb);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
net/ipv4/udp_offload.c: In function ‘udp_gro_receive’:
net/ipv4/udp_offload.c:786:12: error: assignment to ‘struct sk_buff *’ from incompatible pointer type ‘struct skbuff *’ [-Werror=incompatible-pointer-types]
786 | pp = udp_tunnel_gro_rcv(sk, head, skb);
| ^
In file included from ./include/linux/seqlock.h:19,
from ./include/linux/dcache.h:11,
from ./include/linux/fs.h:8,
from ./include/linux/highmem.h:5,
from ./include/linux/bvec.h:10,
from ./include/linux/skbuff.h:17,
from net/ipv4/udp_offload.c:9:
net/ipv4/udp_offload.c: In function ‘udpv4_offload_init’:
net/ipv4/udp_offload.c:936:21: error: ‘udp_tunnel_gro_type_lock’ undeclared (first use in this function); did you mean ‘udp_tunnel_gro_rcv’?
936 | mutex_init(&udp_tunnel_gro_type_lock);
| ^~~~~~~~~~~~~~~~~~~~~~~~
./include/linux/mutex.h:64:23: note: in definition of macro ‘mutex_init’
64 | __mutex_init((mutex), #mutex, &__key); \
| ^~~~~
net/ipv4/udp_offload.c:936:21: note: each undeclared identifier is reported only once for each function it appears in
936 | mutex_init(&udp_tunnel_gro_type_lock);
| ^~~~~~~~~~~~~~~~~~~~~~~~
./include/linux/mutex.h:64:23: note: in definition of macro ‘mutex_init’
64 | __mutex_init((mutex), #mutex, &__key); \
| ^~~~~
cc1: all warnings being treated as errors
--
pw-bot: cr
next prev parent reply other threads:[~2025-03-06 18:50 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-06 15:56 [PATCH net-next 0/2] udp_tunnel: GRO optimizations Paolo Abeni
2025-03-06 15:56 ` [PATCH net-next 1/2] udp_tunnel: create a fast-path GRO lookup Paolo Abeni
2025-03-06 16:35 ` Eric Dumazet
2025-03-06 17:31 ` Paolo Abeni
2025-03-06 19:46 ` Willem de Bruijn
2025-03-06 21:20 ` Paolo Abeni
2025-03-06 22:25 ` Willem de Bruijn
2025-03-06 15:56 ` [PATCH net-next 2/2] udp_tunnel: use static call for GRO hooks when possible Paolo Abeni
2025-03-07 10:53 ` kernel test robot
2025-03-07 12:05 ` kernel test robot
2025-03-06 18:50 ` Jakub Kicinski [this message]
2025-03-06 20:59 ` [PATCH net-next 0/2] udp_tunnel: GRO optimizations Paolo Abeni
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=20250306105046.0aca16b3@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--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 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.