[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7e148fd2-b4b7-49a1-958f-4b0838571245@kernel.org>
Date: Wed, 26 Feb 2025 10:12:08 -0700
From: David Ahern <dsahern@...nel.org>
To: Breno Leitao <leitao@...ian.org>
Cc: Eric Dumazet <edumazet@...gle.com>, Neal Cardwell <ncardwell@...gle.com>,
Kuniyuki Iwashima <kuniyu@...zon.com>, Steven Rostedt <rostedt@...dmis.org>,
Masami Hiramatsu <mhiramat@...nel.org>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
"David S. Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-trace-kernel@...r.kernel.org, kernel-team@...a.com,
yonghong.song@...ux.dev
Subject: Re: [PATCH net-next] trace: tcp: Add tracepoint for tcp_sendmsg()
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
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.
At the time I was looking at latency in the stack - from sendmsg call to
driver pushing descriptors to hardware.
View attachment "0001-tcp-Add-tracepoints-to-tcp_write_xmit-and-tcp_sendms.patch" of type "text/plain" (3337 bytes)
Powered by blists - more mailing lists