[PATCH] udp: Add noinline_for_tracing annotation for udp{,_v6}_send_skb()

[PATCH] udp: Add noinline_for_tracing annotation for udp{,_v6}_send_skb()

[Josh Don]

We hook udp_send_skb() and udp_v6_send_skb() using BPF fentry programs
to monitor UDP transmits. Both functions are static and have two
callers: udp{,v6}_sendmsg() and udp{,_v6}_push_pending_frames().

After an FDO profile update, udp_v6_send_skb() is now inlined into
udpv6_sendmsg(), while an out-of-line copy remains for
udp_v6_push_pending_frames(). The fentry program still attaches
successfully, but it is silently bypassed for all uncorked sends.

To address this, make both functions noinline explicitly for tracing,
as was done for tcp_drop_reason() in commit dbd5e2e79ed8 ("net: tcp:
Add noinline_for_tracing annotation for tcp_drop_reason()").

Assisted-by: LLM
Signed-off-by: Josh Don <joshdon@google.com>
---
 net/ipv4/udp.c | 4 ++--
 net/ipv6/udp.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index b090bd1f59e86..487c8cc8ab206 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1110,8 +1110,8 @@ void udp_set_csum(bool nocheck, struct sk_buff *skb,
 }
 EXPORT_SYMBOL(udp_set_csum);
 
-static int udp_send_skb(struct sk_buff *skb, struct flowi4 *fl4,
-			struct inet_cork *cork)
+noinline_for_tracing static int
+udp_send_skb(struct sk_buff *skb, struct flowi4 *fl4, struct inet_cork *cork)
 {
 	struct sock *sk = skb->sk;
 	int offset, len, datalen;
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 93478d1ad5769..fe92538835176 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -1366,8 +1366,8 @@ static void udp6_hwcsum_outgoing(struct sock *sk, struct sk_buff *skb,
  *	Sending
  */
 
-static int udp_v6_send_skb(struct sk_buff *skb, struct flowi6 *fl6,
-			   struct inet_cork *cork)
+noinline_for_tracing static int
+udp_v6_send_skb(struct sk_buff *skb, struct flowi6 *fl6, struct inet_cork *cork)
 {
 	struct sock *sk = skb->sk;
 	int offset, len, datalen;
-- 
2.56.0.212.g129ede20d9-goog

Re: [PATCH] udp: Add noinline_for_tracing annotation for udp{,_v6}_send_skb()

[Willem de Bruijn]

Josh Don wrote:
> We hook udp_send_skb() and udp_v6_send_skb() using BPF fentry programs
> to monitor UDP transmits. Both functions are static and have two
> callers: udp{,v6}_sendmsg() and udp{,_v6}_push_pending_frames().
> 
> After an FDO profile update, udp_v6_send_skb() is now inlined into
> udpv6_sendmsg(), while an out-of-line copy remains for
> udp_v6_push_pending_frames(). The fentry program still attaches
> successfully, but it is silently bypassed for all uncorked sends.
> 
> To address this, make both functions noinline explicitly for tracing,
> as was done for tcp_drop_reason() in commit dbd5e2e79ed8 ("net: tcp:
> Add noinline_for_tracing annotation for tcp_drop_reason()").
> 
> Assisted-by: LLM
> Signed-off-by: Josh Don <joshdon@google.com>

This would target [PATCH net-next]. But that is closed:

    https://netdev.bots.linux.dev/net-next.html

Please resubmit when the window opens.

The entire function is quite large (though the common hot path would
not be). For that, I expect adding the noinline will be okay.

> ---
>  net/ipv4/udp.c | 4 ++--
>  net/ipv6/udp.c | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> index b090bd1f59e86..487c8cc8ab206 100644
> --- a/net/ipv4/udp.c
> +++ b/net/ipv4/udp.c
> @@ -1110,8 +1110,8 @@ void udp_set_csum(bool nocheck, struct sk_buff *skb,
>  }
>  EXPORT_SYMBOL(udp_set_csum);
>  
> -static int udp_send_skb(struct sk_buff *skb, struct flowi4 *fl4,
> -			struct inet_cork *cork)
> +noinline_for_tracing static int
> +udp_send_skb(struct sk_buff *skb, struct flowi4 *fl4, struct inet_cork *cork)
>  {
>  	struct sock *sk = skb->sk;
>  	int offset, len, datalen;
> diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
> index 93478d1ad5769..fe92538835176 100644
> --- a/net/ipv6/udp.c
> +++ b/net/ipv6/udp.c
> @@ -1366,8 +1366,8 @@ static void udp6_hwcsum_outgoing(struct sock *sk, struct sk_buff *skb,
>   *	Sending
>   */
>  
> -static int udp_v6_send_skb(struct sk_buff *skb, struct flowi6 *fl6,
> -			   struct inet_cork *cork)
> +noinline_for_tracing static int
> +udp_v6_send_skb(struct sk_buff *skb, struct flowi6 *fl6, struct inet_cork *cork)
>  {
>  	struct sock *sk = skb->sk;
>  	int offset, len, datalen;
> -- 
> 2.56.0.212.g129ede20d9-goog
> 

Re: [PATCH] udp: Add noinline_for_tracing annotation for udp{,_v6}_send_skb()

[Kuniyuki Iwashima]

On Mon, 19 Oct 2026 23:07:58 +0000, Josh Don wrote:
> We hook udp_send_skb() and udp_v6_send_skb() using BPF fentry programs
> to monitor UDP transmits. Both functions are static and have two
> callers: udp{,v6}_sendmsg() and udp{,_v6}_push_pending_frames().
> 
> After an FDO profile update, udp_v6_send_skb() is now inlined into
> udpv6_sendmsg(), while an out-of-line copy remains for
> udp_v6_push_pending_frames(). The fentry program still attaches
> successfully, but it is silently bypassed for all uncorked sends.
> 
> To address this, make both functions noinline explicitly for tracing,
> as was done for tcp_drop_reason() in commit dbd5e2e79ed8 ("net: tcp:
> Add noinline_for_tracing annotation for tcp_drop_reason()").

Unlike tcp_drop_reason(), udp_send_skb() is a hot function as
inlined by FDO.

Did you see how this change affects to udp_rr performance ?

Also, net-next is closed.
https://lore.kernel.org/netdev/7a0446eb-8539-4300-ae0b-a3d66a692cbc@redhat.com/


> 
> Assisted-by: LLM
> Signed-off-by: Josh Don <joshdon@google.com>
> ---
>  net/ipv4/udp.c | 4 ++--
>  net/ipv6/udp.c | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> index b090bd1f59e86..487c8cc8ab206 100644
> --- a/net/ipv4/udp.c
> +++ b/net/ipv4/udp.c
> @@ -1110,8 +1110,8 @@ void udp_set_csum(bool nocheck, struct sk_buff *skb,
>  }
>  EXPORT_SYMBOL(udp_set_csum);
>  
> -static int udp_send_skb(struct sk_buff *skb, struct flowi4 *fl4,
> -			struct inet_cork *cork)
> +noinline_for_tracing static int
> +udp_send_skb(struct sk_buff *skb, struct flowi4 *fl4, struct inet_cork *cork)
>  {
>  	struct sock *sk = skb->sk;
>  	int offset, len, datalen;
> diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
> index 93478d1ad5769..fe92538835176 100644
> --- a/net/ipv6/udp.c
> +++ b/net/ipv6/udp.c
> @@ -1366,8 +1366,8 @@ static void udp6_hwcsum_outgoing(struct sock *sk, struct sk_buff *skb,
>   *	Sending
>   */
>  
> -static int udp_v6_send_skb(struct sk_buff *skb, struct flowi6 *fl6,
> -			   struct inet_cork *cork)
> +noinline_for_tracing static int
> +udp_v6_send_skb(struct sk_buff *skb, struct flowi6 *fl6, struct inet_cork *cork)
>  {
>  	struct sock *sk = skb->sk;
>  	int offset, len, datalen;
> -- 
> 2.56.0.212.g129ede20d9-goog
> 

Re: [PATCH] udp: Add noinline_for_tracing annotation for udp{,_v6}_send_skb()

[Jason Xing]

On Tue, Oct 20, 2026 at 7:08 AM Josh Don <joshdon@google.com> wrote:
>
> We hook udp_send_skb() and udp_v6_send_skb() using BPF fentry programs
> to monitor UDP transmits. Both functions are static and have two
> callers: udp{,v6}_sendmsg() and udp{,_v6}_push_pending_frames().
>
> After an FDO profile update, udp_v6_send_skb() is now inlined into
> udpv6_sendmsg(), while an out-of-line copy remains for
> udp_v6_push_pending_frames(). The fentry program still attaches
> successfully, but it is silently bypassed for all uncorked sends.
>
> To address this, make both functions noinline explicitly for tracing,
> as was done for tcp_drop_reason() in commit dbd5e2e79ed8 ("net: tcp:
> Add noinline_for_tracing annotation for tcp_drop_reason()").
>
> Assisted-by: LLM
> Signed-off-by: Josh Don <joshdon@google.com>

I actually mentioned this thing a few times before. The original
thread was from Breno who tried to apply a similar change for tcp
sendmsg. The fact is until now we don't guarantee those functions
should be kept noinline like how uAPI works just for BPF prog. What I
suggested was to select a series of functions in one Doc so that we
could tell people those functions should be noinline or whatever else
just for tracing in a soft way?

Otherwise people would argue there are more functions that should be
done in the same way because they internally trace it.

Willem, Kuniyuki, any thoughts?

Thanks,
Jason

> ---
>  net/ipv4/udp.c | 4 ++--
>  net/ipv6/udp.c | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> index b090bd1f59e86..487c8cc8ab206 100644
> --- a/net/ipv4/udp.c
> +++ b/net/ipv4/udp.c
> @@ -1110,8 +1110,8 @@ void udp_set_csum(bool nocheck, struct sk_buff *skb,
>  }
>  EXPORT_SYMBOL(udp_set_csum);
>
> -static int udp_send_skb(struct sk_buff *skb, struct flowi4 *fl4,
> -                       struct inet_cork *cork)
> +noinline_for_tracing static int
> +udp_send_skb(struct sk_buff *skb, struct flowi4 *fl4, struct inet_cork *cork)
>  {
>         struct sock *sk = skb->sk;
>         int offset, len, datalen;
> diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
> index 93478d1ad5769..fe92538835176 100644
> --- a/net/ipv6/udp.c
> +++ b/net/ipv6/udp.c
> @@ -1366,8 +1366,8 @@ static void udp6_hwcsum_outgoing(struct sock *sk, struct sk_buff *skb,
>   *     Sending
>   */
>
> -static int udp_v6_send_skb(struct sk_buff *skb, struct flowi6 *fl6,
> -                          struct inet_cork *cork)
> +noinline_for_tracing static int
> +udp_v6_send_skb(struct sk_buff *skb, struct flowi6 *fl6, struct inet_cork *cork)
>  {
>         struct sock *sk = skb->sk;
>         int offset, len, datalen;
> --
> 2.56.0.212.g129ede20d9-goog
>
>

Re: [PATCH] udp: Add noinline_for_tracing annotation for udp{,_v6}_send_skb()

[Willem de Bruijn]

Kuniyuki Iwashima wrote:
> On Mon, 19 Oct 2026 23:07:58 +0000, Josh Don wrote:
> > We hook udp_send_skb() and udp_v6_send_skb() using BPF fentry programs
> > to monitor UDP transmits. Both functions are static and have two
> > callers: udp{,v6}_sendmsg() and udp{,_v6}_push_pending_frames().
> > 
> > After an FDO profile update, udp_v6_send_skb() is now inlined into
> > udpv6_sendmsg(), while an out-of-line copy remains for
> > udp_v6_push_pending_frames(). The fentry program still attaches
> > successfully, but it is silently bypassed for all uncorked sends.
> > 
> > To address this, make both functions noinline explicitly for tracing,
> > as was done for tcp_drop_reason() in commit dbd5e2e79ed8 ("net: tcp:
> > Add noinline_for_tracing annotation for tcp_drop_reason()").
> 
> Unlike tcp_drop_reason(), udp_send_skb() is a hot function as
> inlined by FDO.
> 
> Did you see how this change affects to udp_rr performance ?

Yes, maybe I was a bit too fast in assuming that this does not
meaningfully affect performance. A tcp_rr is worthwhile.

Or, since these functions call ip(6)_send_skb, which cannot be
inlined, perhaps a robust obviously free path is to attach BPF
hooks to that (and filter on sk_type and sk_protocol).

Re: [PATCH] udp: Add noinline_for_tracing annotation for udp{,_v6}_send_skb()

[Willem de Bruijn]

Jason Xing wrote:
> On Tue, Oct 20, 2026 at 7:08 AM Josh Don <joshdon@google.com> wrote:
> >
> > We hook udp_send_skb() and udp_v6_send_skb() using BPF fentry programs
> > to monitor UDP transmits. Both functions are static and have two
> > callers: udp{,v6}_sendmsg() and udp{,_v6}_push_pending_frames().
> >
> > After an FDO profile update, udp_v6_send_skb() is now inlined into
> > udpv6_sendmsg(), while an out-of-line copy remains for
> > udp_v6_push_pending_frames(). The fentry program still attaches
> > successfully, but it is silently bypassed for all uncorked sends.
> >
> > To address this, make both functions noinline explicitly for tracing,
> > as was done for tcp_drop_reason() in commit dbd5e2e79ed8 ("net: tcp:
> > Add noinline_for_tracing annotation for tcp_drop_reason()").
> >
> > Assisted-by: LLM
> > Signed-off-by: Josh Don <joshdon@google.com>
> 
> I actually mentioned this thing a few times before. The original
> thread was from Breno who tried to apply a similar change for tcp
> sendmsg. The fact is until now we don't guarantee those functions
> should be kept noinline like how uAPI works just for BPF prog. What I
> suggested was to select a series of functions in one Doc so that we
> could tell people those functions should be noinline or whatever else
> just for tracing in a soft way?
> 
> Otherwise people would argue there are more functions that should be
> done in the same way because they internally trace it.
> 
> Willem, Kuniyuki, any thoughts?

We'll have to review hooks on a case-by-case basis for performance
impact.

If possible, it's preferable to select hooks that cannot be inlined.
Over limiting what the compiler is allowed to do.

Re: [PATCH] udp: Add noinline_for_tracing annotation for udp{,_v6}_send_skb()

[Kuniyuki Iwashima]

On Tue, 20 Oct 2026 09:50:32 -0400, Willem de Bruijn wrote:
> Jason Xing wrote:
> > On Tue, Oct 20, 2026 at 7:08 AM Josh Don <joshdon@google.com> wrote:
> > >
> > > We hook udp_send_skb() and udp_v6_send_skb() using BPF fentry programs
> > > to monitor UDP transmits. Both functions are static and have two
> > > callers: udp{,v6}_sendmsg() and udp{,_v6}_push_pending_frames().
> > >
> > > After an FDO profile update, udp_v6_send_skb() is now inlined into
> > > udpv6_sendmsg(), while an out-of-line copy remains for
> > > udp_v6_push_pending_frames(). The fentry program still attaches
> > > successfully, but it is silently bypassed for all uncorked sends.
> > >
> > > To address this, make both functions noinline explicitly for tracing,
> > > as was done for tcp_drop_reason() in commit dbd5e2e79ed8 ("net: tcp:
> > > Add noinline_for_tracing annotation for tcp_drop_reason()").
> > >
> > > Assisted-by: LLM
> > > Signed-off-by: Josh Don <joshdon@google.com>
> > 
> > I actually mentioned this thing a few times before. The original
> > thread was from Breno who tried to apply a similar change for tcp
> > sendmsg. The fact is until now we don't guarantee those functions
> > should be kept noinline like how uAPI works just for BPF prog. What I
> > suggested was to select a series of functions in one Doc so that we
> > could tell people those functions should be noinline or whatever else
> > just for tracing in a soft way?
> > 
> > Otherwise people would argue there are more functions that should be
> > done in the same way because they internally trace it.
> > 
> > Willem, Kuniyuki, any thoughts?
> 
> We'll have to review hooks on a case-by-case basis for performance
> impact.
> 
> If possible, it's preferable to select hooks that cannot be inlined.
> Over limiting what the compiler is allowed to do.

Agreed, FDO is critical especially for UDP, e.g. udp_rr
w/ 20000 flows will gain high performance boost 14Mpps -> 21Mpps.