Song Liu wrote: > Hi Paolo, > > > On Apr 17, 2025, at 6:17 AM, Paolo Abeni <[email protected]> wrote: > > > > On 4/17/25 1:34 PM, Breno Leitao wrote: > >> On Thu, Apr 17, 2025 at 08:57:24AM +0200, Paolo Abeni wrote: > >>> On 4/16/25 9:23 PM, Breno Leitao wrote: > >>>> Add a lightweight tracepoint to monitor UDP send message operations, > >>>> similar to the recently introduced tcp_sendmsg_locked() trace event in > >>>> commit 0f08335ade712 ("trace: tcp: Add tracepoint for > >>>> tcp_sendmsg_locked()") > >>> > >>> Why is it needed? what would add on top of a plain perf probe, which > >>> will be always available for such function with such argument, as the > >>> function can't be inlined? > >> > >> Why this function can't be inlined? > > > > Because the kernel need to be able find a pointer to it: > > > > .sendmsg = udp_sendmsg, > > > > I'll be really curious to learn how the compiler could inline that. > > It is true that functions that are only used via function pointers > will not be inlined by compilers (at least for those we have tested). > For this reason, we do not worry about functions in various > tcp_congestion_ops. However, udp_sendmsg is also called directly > by udpv6_sendmsg, so it can still get inlined by LTO. > > Thanks, > Song >
I would think that hitting this tracepoint for ipv6_addr_v4mapped addresses is unintentional and surprising, as those would already hit udpv6_sendmsg. On which note, any IPv4 change to UDP needs an equivalent IPv6 one.
