From: Koki Sanagi <sanagi.koki@jp.fujitsu.com>
To: netdev@vger.kernel.org
Cc: izumi.taku@jp.fujitsu.com, kaneshige.kenji@jp.fujitsu.com,
davem@davemloft.net, nhorman@tuxdriver.com,
jeffrey.t.kirsher@intel.com, jesse.brandeburg@intel.com,
bruce.w.allan@intel.com, alexander.h.duyck@intel.com,
peter.p.waskiewicz.jr@intel.com, john.ronciak@intel.com
Subject: [RFC PATCH 0/2] netdev: implement a buffer to log network driver's information
Date: Mon, 05 Apr 2010 15:50:16 +0900 [thread overview]
Message-ID: <4BB98828.5030302@jp.fujitsu.com> (raw)
This patch implements a buffer for recording network driver's message.
This patch extends below patch to make other network driver use it.
http://marc.info/?l=e1000-devel&m=126690500618157&w=2
When I investigate some network driver's trouble, I feel like I want more
detailed debug information, for example, all device register information
(like ethtool -d) when device reset was happened or tx/rx ring's move when
network stream is not smooth etc.
As a recording measure of such information, there are syslog and ftrace now.
but they have some weak points.
Syslog is not appropriate for the size of message is large(ex. recording
all register information) or the number of is large(ex.tracing internal move).
Ftrace is appropriate for recording such messages.
But ftrace has only one buffer for all ftrace event in kernel. As a result,
one adapter's event may be flushed by the others(Of course, syslog has same
weak point).
This patch implements a buffer system which beats those weak points.
Features of that are
1.Each interface can hold respective buffer.
It prevents recorded data from being flowed by other's recorded data.
2.An interface can hold multi-buffers.
It makes one adapter have several buffer for each different purpose.
For example, one is to trace a driver's internal move, the another is to
log error message and some releveant information.
3.resize and on/off per buffer.
if you implement this patch's buffer and you regist buffer in driver's
probe function, all adapter which use that driver must have same size
buffer. If you want trace to one adapter, but not to another, you can make
another adapter's buffer off.
The implementation example of igb is patch 2.
HOW TO USE:
If you want to know how to use from driver side, see patch 2.
User side is below.
# mount -t debugfs nodev /sys/kernel/debug
# ls /sys/kernel/debug/ndrvbuf
igb-trace-0000:03:00.0 igb-trace-0000:03:00.1
# ls /sys/kernel/debug/ndrvbuf/igb-trace-0000:03:00.0
buffer buffer_size
"buffer" is output interface. If you set read_format function in
register_ndrvbuf, it is used. If not, default read function is used.
It displays recorded data by hex style.
# cat buffer
[ 1] 50462.369207: clean_tx qidx=1 ntu=154->156
[ 0] 50462.369241: clean_rx qidx=0 ntu=111->112
[ 0] 50462.369250: xmit qidx=1 ntu=156->158
[ 1] 50462.369256: clean_tx qidx=1 ntu=156->158
[ 1] 50462.369342: clean_rx qidx=0 ntu=113->114
[ 1] 50462.369439: clean_rx qidx=0 ntu=114->115
"buffer_size" is size of buffer per CPU. If you want to change that,
# echo 1000000 > buffer_size
# cat buffer_size
1000000
If you want to disable recording,
# echo 0 > buffer_size
Thanks,
Koki Sanagi.
next reply other threads:[~2010-04-05 6:50 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-05 6:50 Koki Sanagi [this message]
2010-04-05 6:52 ` [RFC PATCH 1/2] netdev: buffer infrastructure to log network driver's information Koki Sanagi
2010-04-05 8:42 ` Eric Dumazet
2010-04-05 19:31 ` David Miller
2010-04-06 0:10 ` Neil Horman
2010-04-06 5:43 ` Koki Sanagi
2010-04-05 6:54 ` [RFC PATCH 2/2] netdev: an usage example on igb Koki Sanagi
2010-04-05 8:30 ` Eric Dumazet
2010-04-06 5:40 ` Koki Sanagi
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=4BB98828.5030302@jp.fujitsu.com \
--to=sanagi.koki@jp.fujitsu.com \
--cc=alexander.h.duyck@intel.com \
--cc=bruce.w.allan@intel.com \
--cc=davem@davemloft.net \
--cc=izumi.taku@jp.fujitsu.com \
--cc=jeffrey.t.kirsher@intel.com \
--cc=jesse.brandeburg@intel.com \
--cc=john.ronciak@intel.com \
--cc=kaneshige.kenji@jp.fujitsu.com \
--cc=netdev@vger.kernel.org \
--cc=nhorman@tuxdriver.com \
--cc=peter.p.waskiewicz.jr@intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.