On Thu, 23 Jul 2026 11:35:40 +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. > > 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]> > --- More detailed AI review Warning: RSS key size likely exceeds the DPNI key limit drivers/net/dpaa2/base/dpaa2_hw_dpni.c Doubling the IP extracts doubles the generated key, not just the extract count. The driver's own accounting treats a NET_PROT_IP full-field address extract as 16 bytes (NH_FLD_IPV6_ADDR_SIZE, see dpaa2_flow_add_ipaddr_extract_rule() in dpaa2_flow.c), so: before: 16 + 16 + 1 = 33 bytes (+4 with L4 = 37) after: 2 * (16 + 16 + 1) = 66 bytes (+4 with L4 = 70) DPNI_MAX_KEY_SIZE is 56, and dpni_attr.fs_key_size is documented as "Size, in bytes, of the flow steering look-up key. Defining a key larger than this when composing the hash + FS key will result in an error." The PMD never reads fs_key_size and there is no size check anywhere on this path, so the first sign of trouble would be dpni_set_rx_hash_dist() failing and rte_eth_dev_configure() returning an error for a plain RTE_ETH_RSS_IP request that works today. Has this been tested on hardware with RTE_ETH_RSS_IP (and IP|TCP|UDP)? If MC accepts it, please say so in the commit message, because the arithmetic says it should not. If the limit is real, the extract set needs to shrink -- dropping NH_FLD_IP_PROTO, or extracting only the inner address pair, would be candidates. Warning: the "inner extract resolves to nothing" claim needs backing Both the commit message and the new comment assert that on a plain frame the HDR_INDEX_LAST extract resolves to nothing and contributes no entropy. The MC header documents hdr_index as "used for protocols that may have more than a single header, 0 indicates an outer header" with NET_PROT_IP taking (0, HDR_INDEX_LAST). The natural reading is that for a single-IP frame the last header *is* the outer one, so index 0 and HDR_INDEX_LAST select the same header and the fields are extracted twice. That is harmless for distribution but it is not what the patch says, and it changes the key size and hash values for every existing non-tunnelled user. Please confirm the actual behaviour with NXP and describe it accurately, one way or the other. This also feeds directly into the key-size question above. Info: duplicate constant +#define DPAA2_DIST_HDR_INDEX_LAST 0xff mc/fsl_net.h already carries LAST_HDR_INDEX (0xFFFFFFFF), truncated to 0xff by the uint8_t hdr_index field. Two differently-named constants for the same hardware encoding in one driver is confusing. Either reuse the existing one with an explicit cast, or add a comment saying this is LAST_HDR_INDEX narrowed to the 8-bit command field. Info: placement The #define sits between two function definitions. Move it up with the other file-scope definitions, or into dpaa2_ethdev.h next to the related driver constants.
