From 0d2993dd8736655c2a8dc91cdbf1a2e3b4bce265 Mon Sep 17 00:00:00 2001 From: raul_chen Date: Mon, 13 Jul 2026 14:16:17 +0800 Subject: [PATCH] Documentation/net: document lower-half driver performance tuning Add a "Performance tuning" section to the network driver guide covering the knobs that matter most for throughput on Wi-Fi lower-half drivers whose MAC runs on a companion core: RX quota as backpressure, keeping the RX thread priority at or below the vendor packet-delivery task, and capping the TCP window / send buffer (backed by the shared IOB pool) on lossy wireless paths. Signed-off-by: raul_chen --- Documentation/components/net/netdriver.rst | 37 ++++++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/Documentation/components/net/netdriver.rst b/Documentation/components/net/netdriver.rst index f35933f6c86..55e7c6b8352 100644 --- a/Documentation/components/net/netdriver.rst +++ b/Documentation/components/net/netdriver.rst @@ -88,6 +88,43 @@ Here is a guide to do so: this replied packet will always be put into ``transmit``, which may exceed the TX quota temporarily. +Performance tuning +================== + +The following knobs matter most for throughput, especially for Wi-Fi drivers +where the MAC runs on a companion core and packets are delivered to the host +over an IPC: + +- **RX quota as backpressure.** The RX quota bounds how many received packets + the driver holds before the upper half drains them. It matters most for + traffic without transport flow control (e.g. UDP): when the peer sends + faster than the socket is drained, a large quota lets the driver copy many + packets into the stack only to drop them at the bounded socket receive + buffer -- wasted work that also steals CPU from the packets that do get + delivered. A smaller quota drops the excess earlier and cheaply, at + ``netpkt_alloc``. For TCP the advertised window already throttles the peer, + so the quota rarely fills. + +- **RX thread priority.** With ``NETDEV_RX_THREAD``, keep ``priority`` at or + below the vendor task that moves packets from the device (companion core) + into the driver. A higher priority (e.g. ``HPWORK``) starves that task, + the device-to-host ring backs up, and packets are dropped upstream of the + driver before ``receive`` ever sees them. + +- **Socket receive buffer.** ``CONFIG_NET_RECV_BUFSIZE`` is the default + SO_RCVBUF: it both caps the advertised TCP window and bounds the UDP + read-ahead, both drawn from the shared IOB pool (``CONFIG_IOB_NBUFFERS`` x + ``CONFIG_IOB_BUFSIZE``). On a lossy wireless path a large TCP window lets + the peer put more in flight than the link can smooth (bursty loss and RTO + stalls), so cap it near the out-of-order reassembly capacity and bound TX + with ``CONFIG_NET_SEND_BUFSIZE``. That same cap limits UDP read-ahead, so a + UDP-throughput-critical socket should raise its own buffer via + ``setsockopt(SO_RCVBUF)`` rather than changing the TCP-safe default. + Enlarging the buffer helps only up to the rate the socket can be drained; + sustained overload is dropped regardless. Keeping out-of-order reassembly + (``CONFIG_NET_TCP_OUT_OF_ORDER``) enabled lets a single loss recover in one + round trip. + "Lower Half" Example ====================