From: Kuniyuki Iwashima <kuniyu@google.com>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: Jason Xing <kerneljasonxing@gmail.com>,
Josh Don <joshdon@google.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@kernel.org>,
Jakub Kicinski <kuba@kernel.org>,
Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] udp: Add noinline_for_tracing annotation for udp{,_v6}_send_skb()
Date: Tue, 20 Oct 2026 16:52:26 +0000 [thread overview]
Message-ID: <ateasbpJlRipuEmi@google.com> (raw)
In-Reply-To: <willemdebruijn.kernel.1a81a5aacc334@gmail.com>
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.
prev parent reply other threads:[~2026-10-20 16:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-19 23:07 [PATCH] udp: Add noinline_for_tracing annotation for udp{,_v6}_send_skb() Josh Don
2026-10-19 23:39 ` Willem de Bruijn
2026-10-20 4:28 ` Kuniyuki Iwashima
2026-10-20 13:49 ` Willem de Bruijn
2026-10-20 6:34 ` Jason Xing
2026-10-20 13:50 ` Willem de Bruijn
2026-10-20 16:52 ` Kuniyuki Iwashima [this message]
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=ateasbpJlRipuEmi@google.com \
--to=kuniyu@google.com \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=horms@kernel.org \
--cc=joshdon@google.com \
--cc=kerneljasonxing@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.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.