On Tue, 25 Aug 2026 09:42:55 +0200
Maxime Leroy <[email protected]> wrote:
> The RSS key only extracted the outer IP header. Tunnelled traffic whose
> outer headers are fixed then carries no entropy for the hash, so every
> flow lands on a single Rx queue.
>
> Extract both the outer IP (header index 0) and the innermost IP instance
> (HDR_INDEX_LAST). Plain frames keep being hashed on their only IP header;
> the inner extract resolves to nothing and adds no entropy. Tunnelled
> frames are also hashed on their inner IP and spread across the Rx queues.
>
> That a lone IP header does not resolve HDR_INDEX_LAST is the regression
> reverted by commit 2b375df07e48 ("net/dpaa2: revert inner RSS level
> support"): extracted only at HDR_INDEX_LAST, every plain frame hashed to
> the same value and landed on one Rx queue.
>
> The worst case, requesting every type the PMD advertises, is 16 extracts
> out of the DPKG_MAX_NUM_OF_EXTRACTS 20. On LX2160A
> dpni_set_rx_hash_dist() accepts the key, and plain IPv4, plain IPv6, VLAN
> tagged and tunnelled IPv6 traffic all spread across the Rx queues.
>
> This is the PMD default hash: dpaa2 does not expose the ethdev RSS level
> selector, so it applies to every RSS request. The hardware cannot hash
> the inner IP alone, as HDR_INDEX_LAST only resolves when several IP
> headers are stacked and a plain frame would hash to a constant. Folding
> the outer IP into the key is therefore unavoidable, and two tunnelled
> flows that share an inner IP but differ in their outer IP may hash to
> different queues. This is documented in the dpaa2 guide.
>
> Signed-off-by: Maxime Leroy <[email protected]>
> ---
Applied to next-net
