Re: [PATCH net-next] trace: tcp: Add tracepoint for tcp_sendmsg()

Hi David,

On Thu, Feb 27, 2025 at 1:14 AM David Ahern [off-list ref] wrote:

On 2/26/25 9:10 AM, Breno Leitao wrote:

quoted

quoted

Also, if a tracepoint is added, inside of tcp_sendmsg_locked would cover
more use cases (see kernel references to it).

Agree, this seems to provide more useful information

quoted

We have a patch for a couple years now with a tracepoint inside the

Sorry, where do you have this patch? is it downstream?

company tree. Attached. Where to put tracepoints and what arguments to
supply so that it is beneficial to multiple users is always a touchy

Right. I am always eager to establish a standard evaluation/method
which developers have common sense in. It's really hard because I gave
it a try before. Maintainers seem not to like to see too many
tracepoints appearing in the stack.

subject :-), so I have not tried to push the patch out. sock arg should
be added to it for example.

The key is to see how tcp_sendmsg_locked breaks up the buffers, and then
another one in tcp_write_xmit to see when the actual push out happens.

Agreed on this point because a fine-grained BPF program can take
advantage of it. But it seems another small topic that is probably
different from what the original motivation from Breno is in this
patch: I guess, making the tcp_sendmsg_locked non-inlined can allow
the BPF program to calculate the delta between when tcp_sendmsg_locked
starts and when tcp_sendmsg_locked ends? I don't know. Probably as
Eric said, using noinline or something like this is simpler?

At the time I was looking at latency in the stack - from sendmsg call to
driver pushing descriptors to hardware.

So do I.

Thanks,
Jason