docs: networking: mention that RSS table should be 4x the queue count

Spell out the recommendation that the RSS table should be
4x the queue count to avoid traffic imbalance. Include minor
rephrasing and removal of the explicit 128 entry example
since a 128 entry table is inadequate on modern machines.

Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260131225454.1225151-2-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This commit is contained in:
Jakub Kicinski 2026-01-31 14:54:54 -08:00
parent 9e3d4dae98
commit ba9c5611f0

View file

@ -38,11 +38,15 @@ that is not the focus of these techniques.
The filter used in RSS is typically a hash function over the network
and/or transport layer headers-- for example, a 4-tuple hash over
IP addresses and TCP ports of a packet. The most common hardware
implementation of RSS uses a 128-entry indirection table where each entry
implementation of RSS uses an indirection table where each entry
stores a queue number. The receive queue for a packet is determined
by masking out the low order seven bits of the computed hash for the
packet (usually a Toeplitz hash), taking this number as a key into the
indirection table and reading the corresponding value.
by indexing the indirection table with the low order bits of the
computed hash for the packet (usually a Toeplitz hash).
The indirection table helps even out the traffic distribution when queue
count is not a power of two. NICs should provide an indirection table
at least 4 times larger than the queue count. 4x table results in ~16%
imbalance between the queues, which is acceptable for most applications.
Some NICs support symmetric RSS hashing where, if the IP (source address,
destination address) and TCP/UDP (source port, destination port) tuples