[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAEEQ3wmc_hPwUc9zeFJ7c0xvmyip7CGHvCHQN2U4c8wyfM1KLA@mail.gmail.com>
Date: Wed, 4 Jan 2023 11:34:53 +0800
From: 运辉崔 <cuiyunhui@...edance.com>
To: Cong Wang <xiyou.wangcong@...il.com>
Cc: edumazet@...gle.com, rostedt@...dmis.org, mhiramat@...nel.org,
davem@...emloft.net, yoshfuji@...ux-ipv6.org, dsahern@...nel.org,
kuba@...nel.org, pabeni@...hat.com, duanxiongchun@...edance.com,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-trace-kernel@...r.kernel.org
Subject: Re: [External] Re: [PATCH] tcp/udp: add tracepoint for send recv length
Cong Wang <xiyou.wangcong@...il.com> 于2023年1月2日周一 03:10写道:
>
> On Thu, Dec 29, 2022 at 04:02:07PM +0800, Yunhui Cui wrote:
> > From: Xiongchun Duan <duanxiongchun@...edance.com>
> >
> > Add a tracepoint for capturing TCP segments with
> > a send or receive length. This makes it easy to obtain
> > the packet sending and receiving information of each process
> > in the user mode, such as the netatop tool.
>
> You can obtain the same information with kretprobe:
> https://www.gcardone.net/2020-07-31-per-process-bandwidth-monitoring-on-Linux-with-bpftrace/
As we know, kprobe gets the result by trapping in an exception, which
loses performance compared to tracepoint.
We did a test for performance comparison. The results are as follows.
Time per request
sock_sendmsg(k,kr): 12.382ms, tcp_send_length(tracepoint): 11.887ms,
without hook:11.222ms
It can be seen that the performance loss of tracepoint is only half of
that of kprobe.
Powered by blists - more mailing lists