[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <02e98f84ee62073e1bf92338f6744fde@localhost>
Date: Wed, 25 Jan 2012 14:27:59 +0100
From: Hagen Paul Pfeifer <hagen@...u.net>
To: Satoru Moriya <satoru.moriya@....com>
Cc: <netdev@...r.kernel.org>, <davem@...emloft.net>,
<nhorman@...driver.com>, <tgraf@...radead.org>,
Stephen Hemminger <stephen.hemminger@...tta.com>,
<eric.dumazet@...il.com>, Seiji Aguchi <seiji.aguchi@....com>
Subject: Re: [PATCH v2 0/2] Tracepoint for tcp retransmission
On Fri, 20 Jan 2012 13:07:02 -0500, Satoru Moriya wrote:
> With this tracepoint, we can know whether the packet drop occurred
> in the server (moreover in the kernel) or not. For example, if we
> finds that retransmission failed (tcp_retransmit_skb() returned
> negative value), it means the kernel may have some troubles at
> that time and we can drill down on issues in the kernel based on
> trace data. OTOH, if retransmission succeeded, packet is dropped
> outside the kernel/server.
This is an equivalent replacement and by means not so intrusive:
probe kernel.function("tcp_retransmit_skb").return {
printf("%s -> %d", probefunc(), retval())
}
and print inet_sk($sk)->inet_num for
kernel.function("tcp_retransmit_skb").
It is crazy to add everywhere new tracepoints. Systemtap is far from being
perfect and as smooth as dtrace. But this is an example where systemtap is
suitable and should be used.
Satoru, you wrote systemtap is not suitable - why?
Hagen
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists