2022-05-19 02:43:46 +03:00
Networking
==========
2017-05-12 15:14:02 +03:00
2022-03-30 07:25:05 +03:00
Refer to :ref: `netdev-FAQ` for a guide on netdev development process specifics.
2017-05-12 15:14:02 +03:00
Contents:
.. toctree ::
:maxdepth: 2
2018-05-02 14:01:36 +03:00
af_xdp
2020-02-24 08:27:50 +03:00
bareudp
2017-07-12 14:14:48 +03:00
batman-adv
2018-01-24 13:19:11 +03:00
can
2018-04-11 19:06:42 +03:00
can_ucan_protocol
2019-05-22 04:57:12 +03:00
device_drivers/index
2019-04-12 14:55:18 +03:00
dsa/index
2020-01-10 01:46:10 +03:00
devlink/index
2020-04-28 01:01:16 +03:00
caif/index
2019-12-27 17:55:18 +03:00
ethtool-netlink
2019-02-27 22:59:13 +03:00
ieee802154
2018-10-08 12:48:36 +03:00
j1939
2017-05-12 15:14:02 +03:00
kapi
2018-01-08 09:50:17 +03:00
msg_zerocopy
2018-07-12 00:42:49 +03:00
failover
2020-04-10 00:21:58 +03:00
net_dim
2018-07-12 00:42:49 +03:00
net_failover
2020-05-01 17:44:58 +03:00
page_pool
2019-01-26 13:25:37 +03:00
phy
2019-02-22 14:31:46 +03:00
sfp-phylink
2018-07-18 06:27:35 +03:00
alias
2018-07-18 06:27:36 +03:00
bridge
2018-11-11 00:38:12 +03:00
snmp_counter
2019-01-06 02:29:41 +03:00
checksum-offloads
segmentation-offloads
2019-01-18 23:38:32 +03:00
scaling
2019-05-22 04:57:13 +03:00
tls
2019-05-22 04:57:14 +03:00
tls-offload
2023-04-17 17:32:33 +03:00
tls-handshake
2019-11-22 10:43:06 +03:00
nfc
2020-02-06 18:17:22 +03:00
6lowpan
2020-04-28 01:01:17 +03:00
6pack
2020-04-28 01:01:19 +03:00
arcnet-hardware
2020-04-28 01:01:20 +03:00
arcnet
2020-04-28 01:01:21 +03:00
atm
2020-04-28 01:01:22 +03:00
ax25
2020-04-28 01:01:24 +03:00
bonding
2020-04-28 01:01:25 +03:00
cdc_mbim
2020-04-28 01:01:28 +03:00
dccp
2020-04-28 01:01:29 +03:00
dctcp
2020-04-28 01:01:32 +03:00
dns_resolver
2020-04-28 01:01:33 +03:00
driver
2020-04-28 01:01:34 +03:00
eql
2020-04-28 01:01:35 +03:00
fib_trie
2020-04-28 01:01:36 +03:00
filter
2020-04-28 01:01:39 +03:00
generic-hdlc
2020-04-28 01:01:40 +03:00
generic_netlink
2020-04-28 01:01:41 +03:00
gen_stats
2020-04-28 01:01:42 +03:00
gtp
2020-04-28 01:01:44 +03:00
ila
2021-07-28 18:59:12 +03:00
ioam6-sysctl
2020-04-28 01:01:45 +03:00
ipddp
2020-04-28 01:01:46 +03:00
ip_dynaddr
2020-04-28 01:01:48 +03:00
ipsec
2020-04-28 01:01:49 +03:00
ip-sysctl
2020-04-28 01:01:50 +03:00
ipv6
2020-04-28 01:01:51 +03:00
ipvlan
2020-04-28 01:01:52 +03:00
ipvs-sysctl
2020-04-28 01:01:53 +03:00
kcm
2020-04-30 19:03:56 +03:00
l2tp
2020-04-30 19:03:57 +03:00
lapb-module
2020-04-30 19:03:59 +03:00
mac80211-injection
2021-07-29 05:20:53 +03:00
mctp
2020-04-30 19:04:00 +03:00
mpls-sysctl
2020-11-03 22:05:08 +03:00
mptcp-sysctl
2020-04-30 19:04:01 +03:00
multiqueue
2023-03-22 08:38:48 +03:00
napi
2020-04-30 19:04:02 +03:00
netconsole
2020-04-30 19:04:03 +03:00
netdev-features
2020-04-30 19:04:04 +03:00
netdevices
2020-04-30 19:04:05 +03:00
netfilter-sysctl
2020-04-30 19:04:06 +03:00
netif-msg
2021-03-29 18:57:31 +03:00
nexthop-group-resilient
2020-04-30 19:04:07 +03:00
nf_conntrack-sysctl
2020-04-30 19:04:08 +03:00
nf_flowtable
2020-04-30 19:04:09 +03:00
openvswitch
2020-04-30 19:04:10 +03:00
operstates
2020-04-30 19:04:11 +03:00
packet_mmap
2020-04-30 19:04:12 +03:00
phonet
2020-04-30 19:04:13 +03:00
pktgen
2020-04-30 19:04:14 +03:00
plip
2020-04-30 19:04:15 +03:00
ppp_generic
2020-04-30 19:04:16 +03:00
proc_net_tcp
2020-04-30 19:04:17 +03:00
radiotap-headers
2020-04-30 19:04:19 +03:00
rds
2020-04-30 19:04:20 +03:00
regulatory
2022-09-05 16:55:57 +03:00
representors
2020-04-30 19:04:21 +03:00
rxrpc
2020-04-30 19:04:22 +03:00
sctp
2020-04-30 19:04:23 +03:00
secid
2020-04-30 19:04:24 +03:00
seg6-sysctl
2022-05-09 19:04:55 +03:00
skbuff
2022-03-03 14:35:27 +03:00
smc-sysctl
net: tighten the definition of interface statistics
This patch is born out of an investigation into which IEEE statistics
correspond to which struct rtnl_link_stats64 members. Turns out that
there seems to be reasonable consensus on the matter, among many drivers.
To save others the time (and it took more time than I'm comfortable
admitting) I'm adding comments referring to IEEE attributes to
struct rtnl_link_stats64.
Up until now we had two forms of documentation for stats - in
Documentation/ABI/testing/sysfs-class-net-statistics and the comments
on struct rtnl_link_stats64 itself. While the former is very cautious
in defining the expected behavior, the latter feel quite dated and
may not be easy to understand for modern day driver author
(e.g. rx_over_errors). At the same time modern systems are far more
complex and once obvious definitions lost their clarity. For example
- does rx_packet count at the MAC layer (aFramesReceivedOK)?
packets processed correctly by hardware? received by the driver?
or maybe received by the stack?
I tried to clarify the expectations, further clarifications from
others are very welcome.
The part hardest to untangle is rx_over_errors vs rx_fifo_errors
vs rx_missed_errors. After much deliberation I concluded that for
modern HW only two of the counters will make sense. The distinction
between internal FIFO overflow and packets dropped due to back-pressure
from the host is likely too implementation (driver and device) specific
to expose in the standard stats.
Now - which two of those counters we select to use is anyone's pick:
sysfs documentation suggests rx_over_errors counts packets which
did not fit into buffers due to MTU being too small, which I reused.
There don't seem to be many modern drivers using it (well, CAN drivers
seem to love this statistic).
Of the remaining two I picked rx_missed_errors to report device drops.
bnxt reports it and it's folded into "drop"s in procfs (while
rx_fifo_errors is an error, and modern devices usually receive the frame
OK, they just can't admit it into the pipeline).
Of the drivers I looked at only AMD Lance-like and NS8390-like use all
three of these counters. rx_missed_errors counts missed frames,
rx_over_errors counts overflow events, and rx_fifo_errors counts frames
which were truncated because they didn't fit into buffers. This suggests
that rx_fifo_errors may be the correct stat for truncated packets, but
I'd think a FIFO stat counting truncated packets would be very confusing
to a modern reader.
v2:
- add driver developer notes about ethtool stat count and reset
- replace Ethernet with IEEE 802.3 to better indicate source of attrs
- mention byte counters don't count FCS
- clarify RX counter is from device to host
- drop "sightly" from sysfs paragraph
- add examples of ethtool stats
- s/incoming/received/ s/incoming/transmitted/
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-09-04 02:14:31 +03:00
statistics
2020-04-30 19:04:26 +03:00
strparser
2020-04-30 19:04:27 +03:00
switchdev
2020-10-09 10:01:28 +03:00
sysfs-tagging
2020-04-30 19:04:28 +03:00
tc-actions-env-rules
2022-10-21 10:58:50 +03:00
tc-queue-filters
2020-04-30 19:04:29 +03:00
tcp-thin
2020-04-30 19:04:30 +03:00
team
2020-04-30 19:04:31 +03:00
timestamping
2020-11-29 21:32:51 +03:00
tipc
2020-04-30 19:04:32 +03:00
tproxy
2020-05-01 17:44:23 +03:00
tuntap
2020-05-01 17:44:24 +03:00
udplite
2020-05-01 17:44:25 +03:00
vrf
2020-05-01 17:44:26 +03:00
vxlan
2020-05-01 17:44:28 +03:00
x25
2023-05-10 05:29:14 +03:00
x25-iface
2020-05-01 17:44:29 +03:00
xfrm_device
2020-05-01 17:44:30 +03:00
xfrm_proc
2020-05-01 17:44:31 +03:00
xfrm_sync
2020-05-01 17:44:32 +03:00
xfrm_sysctl
2023-01-20 01:15:20 +03:00
xdp-rx-metadata
2017-05-12 15:14:02 +03:00
2019-07-26 15:51:29 +03:00
.. only :: subproject and html
2017-05-12 15:14:02 +03:00
Indices
=======
* :ref: `genindex`