Hi David, On Thu, Feb 27, 2025 at 1:14 AM David Ahern <[email protected]> wrote: > > On 2/26/25 9:10 AM, Breno Leitao wrote: > >> 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 > > > >> 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
