[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <65795E11DBF1E645A09CEC7EAEE94B9CB5AFA64F@USINDEVS02.corp.hds.com>
Date: Fri, 16 Dec 2011 17:14:53 -0500
From: Satoru Moriya <satoru.moriya@....com>
To: "netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC: "nhorman@...driver.com" <nhorman@...driver.com>,
"davem@...emloft.net" <davem@...emloft.net>,
"tgraf@...radead.org" <tgraf@...radead.org>,
Seiji Aguchi <seiji.aguchi@....com>,
"dle-develop@...ts.sourceforge.net"
<dle-develop@...ts.sourceforge.net>
Subject: [PATCH 0/2] Tracepoint for tcp retransmission
Sometimes network packets are dropped for some reason. In enterprise
systems which require strict RAS functionality, we must know the
reason why it happened and explain it to our customers even if using
TCP. When we investigate the incidents, at first we try to find out
whether the problem is in the server(kernel, application) or else
(router, hub etc). And next we try to find out which layer
(application/middleware/kernel(IP/TCP/UDP/..)etc.) the problem
occurs.
In application layer, user applications and/or middlewares usually
save logs if they dropped packets. In kernel layer, with this
tracepoint, we are able to know whether the kernel(TCP layer) send
packets successfully or not.
With a combination of them, we can find out whether the problem is
in the server or not.
Satoru Moriya (2):
tcp: refactor tcp_retransmit_skb() for a single return point
tcp: add tracepoint for tcp retransmission
include/trace/events/tcp.h | 35 +++++++++++++++++++++++++++++++++++
net/core/net-traces.c | 1 +
net/ipv4/tcp_output.c | 34 ++++++++++++++++++++++++----------
3 files changed, 60 insertions(+), 10 deletions(-)
create mode 100644 include/trace/events/tcp.h
--
1.7.6.4
--
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