netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Satoru Moriya <satoru.moriya@hds.com>
To: "netdev@vger.kernel.org" <netdev@vger.kernel.org>
Cc: "davem@davemloft.net" <davem@davemloft.net>,
	"nhorman@tuxdriver.com" <nhorman@tuxdriver.com>,
	"tgraf@infradead.org" <tgraf@infradead.org>,
	Stephen Hemminger <stephen.hemminger@vyatta.com>,
	Hagen Paul Pfeifer <hagen@jauu.net>,
	"eric.dumazet@gmail.com" <eric.dumazet@gmail.com>,
	Seiji Aguchi <seiji.aguchi@hds.com>
Subject: [PATCH v2 0/2] Tracepoint for tcp retransmission
Date: Fri, 20 Jan 2012 13:07:02 -0500	[thread overview]
Message-ID: <65795E11DBF1E645A09CEC7EAEE94B9CB728DD67@USINDEVS02.corp.hds.com> (raw)

Change log v1 -> v2
- rewrite a patch description based on replies to v1 patchset
- add local port number to tracedata

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 packet drop is in the server(kernel, application) or else
(router, hub etc). Once we find it happened in the kernel, we try to
get more details.

Currently, there are some tools/interfaces, e.g. tcpdump,
dropwatch/skb:kfree_skb(tracepoint), netstat, /proc, systemtap etc, 
which help us analyze situations.
But unfortunately, they are too much for one, not enough for
the other. tcpdump captures all the packet but it's overkill because
we don't need all the packets' data but just dropped one. We can
get statistics via netstat and/or /proc but we need more information
to analyze the situation. skb:kfree_skb tracepoint is very useful
for detecting packet drop and analyzing it. In addition to it, if
we have tracepoints in TCP layer in particular retransmit path,
it is very helpful for us to dig into situations because with TCP
the kernel tries to resend packets before dropping them.

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.


Satoru Moriya (2):
  tcp: refactor tcp_retransmit_skb() for a single return point
  tcp: add tracepoint for tcp retransmission

 include/trace/events/tcp.h |   38 ++++++++++++++++++++++++++++++++++++++
 net/core/net-traces.c      |    1 +
 net/ipv4/tcp_output.c      |   34 ++++++++++++++++++++++++----------
 3 files changed, 63 insertions(+), 10 deletions(-)
 create mode 100644 include/trace/events/tcp.h

-- 
1.7.6.4

             reply	other threads:[~2012-01-20 18:07 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-20 18:07 Satoru Moriya [this message]
2012-01-20 18:08 ` [PATCH v2 1/2] tcp: refactor tcp_retransmit_skb() for a single return point Satoru Moriya
2012-01-20 18:09 ` [PATCH v2 2/2] tcp: add tracepoint for tcp retransmission Satoru Moriya
2012-01-20 18:50 ` [PATCH v2 0/2] Tracepoint " David Miller
2012-02-03 21:47   ` Satoru Moriya
2012-02-04  4:40     ` Yuchung Cheng
2012-02-06 18:32       ` Satoru Moriya
2012-02-04 14:28     ` Neil Horman
2012-02-04 15:58       ` Hagen Paul Pfeifer
2012-02-04 20:09         ` Neil Horman
2012-02-05 12:53           ` Frank Ch. Eigler
2012-02-05 19:17             ` Neil Horman
2012-02-05 20:04               ` Hagen Paul Pfeifer
2012-02-05 21:48                 ` David Miller
2012-02-06  1:32                 ` Neil Horman
2012-02-06 15:20                   ` Frank Ch. Eigler
2012-02-06 15:24                     ` Eric Dumazet
2012-02-06 15:38                       ` Neil Horman
2012-02-06 15:53                     ` Neil Horman
2012-02-06 16:18                       ` Steven Rostedt
2012-02-06 17:02                         ` Eric Dumazet
2012-02-06 17:18                           ` Steven Rostedt
2012-02-06 16:21                       ` Frank Ch. Eigler
2012-02-06 18:21                       ` Satoru Moriya
2012-01-25 13:27 ` Hagen Paul Pfeifer
2012-01-25 14:44   ` Eric Dumazet
2012-01-26 18:51     ` David Miller
2012-02-03 20:31     ` Satoru Moriya
2012-02-03 20:43   ` Satoru Moriya
2012-02-03 20:55     ` Hagen Paul Pfeifer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=65795E11DBF1E645A09CEC7EAEE94B9CB728DD67@USINDEVS02.corp.hds.com \
    --to=satoru.moriya@hds.com \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=hagen@jauu.net \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@tuxdriver.com \
    --cc=seiji.aguchi@hds.com \
    --cc=stephen.hemminger@vyatta.com \
    --cc=tgraf@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).