> On Apr 17, 2025, at 8:48 AM, Willem de Bruijn
> <willemdebruijn.ker...@gmail.com> wrote:
>
> Song Liu wrote:
>> Hi Paolo,
>>
>>> On Apr 17, 2025, at 6:17 AM, Paolo Abeni <pab...@redhat.com> 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.
It is up to the user to decide how these tracepoints should be
used. For example, the user may only be interested in
udpv6_sendmsg => udp_sendmsg case. Without a tracepoint, the user
has to understand whether the compiler inlined this function.
>
> On which note, any IPv4 change to UDP needs an equivalent IPv6 one.
Do you mean we need to also add tracepoints for udpv6_sendmsg?
Thanks,
Song
