mirror of https://github.com/torvalds/linux.git
f22cc6f766
Some modern NICs support including the IPv6 Flow Label in the flow hash for RSS queue selection. This is outside the old "Microsoft spec", but was included in the OCP NIC spec: [ ] RSS include flow label in the hash (configurable) https://www.opencompute.org/w/index.php?title=Core_Offloads#Receive_Side_Scaling RSS Flow Label hashing allows TCP Protective Load Balancing (PLB) to recover from receiver congestion / overload. Rx CPU/queue hotspots are relatively common for data ingest workloads, and so far we had to try to detect the condition at the RPC layer and reopen the connection. PLB lets us change the Flow Label and therefore Rx CPU on RTO, with minimal packet reordering. PLB reaction times are much faster, and can happen at any point in the connection, not just at RPC boundaries. Due to the nature of host processing (relatively long queues, other kernel subsystems masking IRQs for 100s of msecs) the risk of reordering within the host is higher than in the network. But for applications which need it - it is far preferable to potentially persistent overload of subset of queues. It is expected that the hash communicated to the host may change if the Flow Label changes. This may be surprising to some host software, but I don't expect the devices can compute two Toeplitz hashes, one with the Flow Label for queue selection and one without for the rx hash communicated to the host. Besides, changing the hash may potentially help to change the path thru host queues. User can disable NETIF_F_RXHASH if they require a stable flow hash. The name RXH_IP6_FL was chosen based on what we call Flow Label variables in IPv6 processing (fl). I prefer fl_lbl but that appears to be an fbnic-only spelling. We could spell out RXH_IP6_FLOW_LABEL but existing RXH_ defines are a lot more terse. Willem notes [1] that Flow Label is defined as identifying the flow and therefore including both the flow label _and_ the L4 header fields is not generally necessary. But it should not hurt so it's not explicitly prevented if the driver supports hashing on both at the same time. Link: https://lore.kernel.org/68483433b45e2_3cd66f29440@willemb.c.googlers.com.notmuch [1] Signed-off-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Joe Damato <joe@dama.to> Link: https://patch.msgid.link/20250811234212.580748-2-kuba@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com> |
||
|---|---|---|
| .. | ||
| Makefile | ||
| bitset.c | ||
| bitset.h | ||
| cabletest.c | ||
| channels.c | ||
| cmis.h | ||
| cmis_cdb.c | ||
| cmis_fw_update.c | ||
| coalesce.c | ||
| common.c | ||
| common.h | ||
| debug.c | ||
| eee.c | ||
| eeprom.c | ||
| features.c | ||
| fec.c | ||
| ioctl.c | ||
| linkinfo.c | ||
| linkmodes.c | ||
| linkstate.c | ||
| mm.c | ||
| module.c | ||
| module_fw.h | ||
| netlink.c | ||
| netlink.h | ||
| pause.c | ||
| phc_vclocks.c | ||
| phy.c | ||
| plca.c | ||
| privflags.c | ||
| pse-pd.c | ||
| rings.c | ||
| rss.c | ||
| stats.c | ||
| strset.c | ||
| ts.h | ||
| tsconfig.c | ||
| tsinfo.c | ||
| tunnels.c | ||
| wol.c | ||