Skip to content

RFC netdev: implement a buffer to log network driver's information

Koki Sanagi netdev 1 version In review

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 RFC Latest2 patches 6 repliesIn review

Patches in v1 No applies recorded yet

#Subject and filesSizeRepliesApplied
1/2netdev: buffer infrastructure to log network driver's informationdrivers/net/Kconfig drivers/net/Makefile drivers/net/ndrvbuf.c +1 more+601 -04 replies
2/2netdev: an usage example on igbdrivers/net/igb/Makefile drivers/net/igb/igb.h drivers/net/igb/igb_main.c +2 more+113 -22 replies

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

Cover letter [RFC PATCH 0/2] netdev: implement a buffer to log network driver's information

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.