2024-01-31 10:21:49 +00:00
|
|
|
What: /sys/class/net/<iface>/queues/rx-<queue>/rps_cpus
|
2014-05-23 23:35:41 +00:00
|
|
|
Date: March 2010
|
|
|
|
|
KernelVersion: 2.6.35
|
|
|
|
|
Contact: netdev@vger.kernel.org
|
|
|
|
|
Description:
|
|
|
|
|
Mask of the CPU(s) currently enabled to participate into the
|
|
|
|
|
Receive Packet Steering packet processing flow for this
|
|
|
|
|
network device queue. Possible values depend on the number
|
|
|
|
|
of available CPU(s) in the system.
|
|
|
|
|
|
2024-01-31 10:21:49 +00:00
|
|
|
What: /sys/class/net/<iface>/queues/rx-<queue>/rps_flow_cnt
|
2014-05-23 23:35:41 +00:00
|
|
|
Date: April 2010
|
|
|
|
|
KernelVersion: 2.6.35
|
|
|
|
|
Contact: netdev@vger.kernel.org
|
|
|
|
|
Description:
|
|
|
|
|
Number of Receive Packet Steering flows being currently
|
|
|
|
|
processed by this particular network device receive queue.
|
|
|
|
|
|
2024-01-31 10:21:49 +00:00
|
|
|
What: /sys/class/net/<iface>/queues/tx-<queue>/tx_timeout
|
2014-05-23 23:35:41 +00:00
|
|
|
Date: November 2011
|
|
|
|
|
KernelVersion: 3.3
|
|
|
|
|
Contact: netdev@vger.kernel.org
|
|
|
|
|
Description:
|
|
|
|
|
Indicates the number of transmit timeout events seen by this
|
|
|
|
|
network interface transmit queue.
|
|
|
|
|
|
2024-01-31 10:21:49 +00:00
|
|
|
What: /sys/class/net/<iface>/queues/tx-<queue>/tx_maxrate
|
2015-03-18 12:57:33 +00:00
|
|
|
Date: March 2015
|
|
|
|
|
KernelVersion: 4.1
|
|
|
|
|
Contact: netdev@vger.kernel.org
|
|
|
|
|
Description:
|
|
|
|
|
A Mbps max-rate set for the queue, a value of zero means disabled,
|
|
|
|
|
default is disabled.
|
|
|
|
|
|
2024-01-31 10:21:49 +00:00
|
|
|
What: /sys/class/net/<iface>/queues/tx-<queue>/xps_cpus
|
2014-05-23 23:35:41 +00:00
|
|
|
Date: November 2010
|
|
|
|
|
KernelVersion: 2.6.38
|
|
|
|
|
Contact: netdev@vger.kernel.org
|
|
|
|
|
Description:
|
|
|
|
|
Mask of the CPU(s) currently enabled to participate into the
|
|
|
|
|
Transmit Packet Steering packet processing flow for this
|
2023-08-14 21:28:20 +00:00
|
|
|
network device transmit queue. Possible values depend on the
|
2014-05-23 23:35:41 +00:00
|
|
|
number of available CPU(s) in the system.
|
|
|
|
|
|
2024-01-31 10:21:49 +00:00
|
|
|
What: /sys/class/net/<iface>/queues/tx-<queue>/xps_rxqs
|
2018-06-30 04:27:12 +00:00
|
|
|
Date: June 2018
|
|
|
|
|
KernelVersion: 4.18.0
|
|
|
|
|
Contact: netdev@vger.kernel.org
|
|
|
|
|
Description:
|
|
|
|
|
Mask of the receive queue(s) currently enabled to participate
|
|
|
|
|
into the Transmit Packet Steering packet processing flow for this
|
|
|
|
|
network device transmit queue. Possible values depend on the
|
|
|
|
|
number of available receive queue(s) in the network device.
|
|
|
|
|
Default is disabled.
|
|
|
|
|
|
2024-01-31 10:21:49 +00:00
|
|
|
What: /sys/class/net/<iface>/queues/tx-<queue>/byte_queue_limits/hold_time
|
2014-05-23 23:35:41 +00:00
|
|
|
Date: November 2011
|
|
|
|
|
KernelVersion: 3.3
|
|
|
|
|
Contact: netdev@vger.kernel.org
|
|
|
|
|
Description:
|
|
|
|
|
Indicates the hold time in milliseconds to measure the slack
|
|
|
|
|
of this particular network device transmit queue.
|
|
|
|
|
Default value is 1000.
|
|
|
|
|
|
2024-01-31 10:21:49 +00:00
|
|
|
What: /sys/class/net/<iface>/queues/tx-<queue>/byte_queue_limits/inflight
|
2014-05-23 23:35:41 +00:00
|
|
|
Date: November 2011
|
|
|
|
|
KernelVersion: 3.3
|
|
|
|
|
Contact: netdev@vger.kernel.org
|
|
|
|
|
Description:
|
|
|
|
|
Indicates the number of bytes (objects) in flight on this
|
|
|
|
|
network device transmit queue.
|
|
|
|
|
|
2024-01-31 10:21:49 +00:00
|
|
|
What: /sys/class/net/<iface>/queues/tx-<queue>/byte_queue_limits/limit
|
2014-05-23 23:35:41 +00:00
|
|
|
Date: November 2011
|
|
|
|
|
KernelVersion: 3.3
|
|
|
|
|
Contact: netdev@vger.kernel.org
|
|
|
|
|
Description:
|
|
|
|
|
Indicates the current limit of bytes allowed to be queued
|
|
|
|
|
on this network device transmit queue. This value is clamped
|
|
|
|
|
to be within the bounds defined by limit_max and limit_min.
|
|
|
|
|
|
2024-01-31 10:21:49 +00:00
|
|
|
What: /sys/class/net/<iface>/queues/tx-<queue>/byte_queue_limits/limit_max
|
2014-05-23 23:35:41 +00:00
|
|
|
Date: November 2011
|
|
|
|
|
KernelVersion: 3.3
|
|
|
|
|
Contact: netdev@vger.kernel.org
|
|
|
|
|
Description:
|
|
|
|
|
Indicates the absolute maximum limit of bytes allowed to be
|
|
|
|
|
queued on this network device transmit queue. See
|
|
|
|
|
include/linux/dynamic_queue_limits.h for the default value.
|
|
|
|
|
|
2024-01-31 10:21:49 +00:00
|
|
|
What: /sys/class/net/<iface>/queues/tx-<queue>/byte_queue_limits/limit_min
|
2014-05-23 23:35:41 +00:00
|
|
|
Date: November 2011
|
|
|
|
|
KernelVersion: 3.3
|
|
|
|
|
Contact: netdev@vger.kernel.org
|
|
|
|
|
Description:
|
|
|
|
|
Indicates the absolute minimum limit of bytes allowed to be
|
|
|
|
|
queued on this network device transmit queue. Default value is
|
|
|
|
|
0.
|
net: dqs: add NIC stall detector based on BQL
softnet_data->time_squeeze is sometimes used as a proxy for
host overload or indication of scheduling problems. In practice
this statistic is very noisy and has hard to grasp units -
e.g. is 10 squeezes a second to be expected, or high?
Delaying network (NAPI) processing leads to drops on NIC queues
but also RTT bloat, impacting pacing and CA decisions.
Stalls are a little hard to detect on the Rx side, because
there may simply have not been any packets received in given
period of time. Packet timestamps help a little bit, but
again we don't know if packets are stale because we're
not keeping up or because someone (*cough* cgroups)
disabled IRQs for a long time.
We can, however, use Tx as a proxy for Rx stalls. Most drivers
use combined Rx+Tx NAPIs so if Tx gets starved so will Rx.
On the Tx side we know exactly when packets get queued,
and completed, so there is no uncertainty.
This patch adds stall checks to BQL. Why BQL? Because
it's a convenient place to add such checks, already
called by most drivers, and it has copious free space
in its structures (this patch adds no extra cache
references or dirtying to the fast path).
The algorithm takes one parameter - max delay AKA stall
threshold and increments a counter whenever NAPI got delayed
for at least that amount of time. It also records the length
of the longest stall.
To be precise every time NAPI has not polled for at least
stall thrs we check if there were any Tx packets queued
between last NAPI run and now - stall_thrs/2.
Unlike the classic Tx watchdog this mechanism does not
ignore stalls caused by Tx being disabled, or loss of link.
I don't think the check is worth the complexity, and
stall is a stall, whether due to host overload, flow
control, link down... doesn't matter much to the application.
We have been running this detector in production at Meta
for 2 years, with the threshold of 8ms. It's the lowest
value where false positives become rare. There's still
a constant stream of reported stalls (especially without
the ksoftirqd deferral patches reverted), those who like
their stall metrics to be 0 may prefer higher value.
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Breno Leitao <leitao@debian.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2024-03-04 14:08:47 +00:00
|
|
|
|
|
|
|
|
What: /sys/class/net/<iface>/queues/tx-<queue>/byte_queue_limits/stall_thrs
|
|
|
|
|
Date: Jan 2024
|
|
|
|
|
KernelVersion: 6.9
|
|
|
|
|
Contact: netdev@vger.kernel.org
|
|
|
|
|
Description:
|
|
|
|
|
Tx completion stall detection threshold in ms. Kernel will
|
|
|
|
|
guarantee to detect all stalls longer than this threshold but
|
|
|
|
|
may also detect stalls longer than half of the threshold.
|
|
|
|
|
|
|
|
|
|
What: /sys/class/net/<iface>/queues/tx-<queue>/byte_queue_limits/stall_cnt
|
|
|
|
|
Date: Jan 2024
|
|
|
|
|
KernelVersion: 6.9
|
|
|
|
|
Contact: netdev@vger.kernel.org
|
|
|
|
|
Description:
|
|
|
|
|
Number of detected Tx completion stalls.
|
|
|
|
|
|
|
|
|
|
What: /sys/class/net/<iface>/queues/tx-<queue>/byte_queue_limits/stall_max
|
|
|
|
|
Date: Jan 2024
|
|
|
|
|
KernelVersion: 6.9
|
|
|
|
|
Contact: netdev@vger.kernel.org
|
|
|
|
|
Description:
|
|
|
|
|
Longest detected Tx completion stall. Write 0 to clear.
|