On Thu, Jul 16, 2026 at 9:48 AM Hemant Agrawal <[email protected]> wrote: > > > On 15-07-2026 22:30, Maxime Leroy wrote: > > Hi Hemant, > > Do you have any preference between the different approaches proposed below? > > Regards, > > Maxime Leroy > > On Tue, Jun 30, 2026 at 2:39 PM Maxime Leroy <[email protected]> wrote: > > When RTE_ETH_RSS_LEVEL_INNERMOST is requested, the IP key extracts use > the innermost header index (HDR_INDEX_LAST). The hardware only resolves > that index when several IP headers are stacked: for a non-tunnelled > frame, which carries a single IP header, the extraction returns nothing. > The RSS hash is then constant and all such frames are steered to a > single Rx queue. > > Always also extract the outer IP (header index 0), which the hardware > resolves for any frame. Non-tunnelled frames are thus hashed on their > only IP header, while tunnelled frames keep being hashed on their inner > IP. > > This is a deliberate tradeoff: the ethdev API defines > RTE_ETH_RSS_LEVEL_INNERMOST as hashing the innermost header only, but the > hardware cannot do that without breaking RSS for plain traffic. As a > consequence, two tunnelled flows with the same inner header but > different outer IPs may hash to different queues. This limitation is > documented in the dpaa2 guide. > > Alternatives considered (feedback welcome, hence RFC): > > - Hash both outer and inner only under RTE_ETH_RSS_LEVEL_PMD_DEFAULT and > keep INNERMOST strictly inner-only. The ethdev API leaves the default > level to the PMD, so this stays API-compliant; it changes the default > hash for tunnelled traffic. > > - Add a generic RTE_ETH_RSS_LEVEL_OUTER_INNER value to the ethdev API so > applications can request hashing on both encapsulation levels > explicitly, instead of overloading INNERMOST. This needs an ethdev API > change and agreement from other PMDs. > > Fixes: 32f701671d2f ("net/dpaa2: support inner RSS level for tunnelled > traffic") > Signed-off-by: Maxime Leroy <[email protected]> > > Hi Maxime, > > My preference is to keep RTE_ETH_RSS_LEVEL_INNERMOST semantics unchanged and > strictly hash on the innermost header. > > I would rather use the PMD-defined default level to provide the best RSS > distribution for both plain and tunnelled traffic. Overloading INNERMOST to > include the outer IP makes the behavior diverge from the ethdev definition > and may surprise applications relying on true inner-header affinity. > > Longer term, an explicit OUTER_INNER RSS level would be the cleanest solution > if there is interest from other PMDs. > > Regards, > > Hemant
Thanks for the feedback, but I have a concern with keeping INNERMOST strictly inner-only on dpaa2. The ethdev API defines INNERMOST in terms of the innermost encapsulation level, not the presence of a tunnel. A plain frame has a single level, so its innermost header is its only IP header, and INNERMOST must hash it. Collapsing all non-tunnelled traffic onto one queue is not "strict inner-only", it is broken RSS for the common case. dpaa2 cannot express true innermost-only: we map innermost to HDR_INDEX_LAST, which only resolves when at least two IP headers are stacked. For a single header nothing resolves, hence the constant hash today. The only way to hash a plain frame's IP is to also extract header index 0 (always resolves), which unavoidably folds the outer IP into the hash for tunnelled frames. I can move the outer+inner extraction under PMD_DEFAULT as you suggest. But that leaves only two options for INNERMOST on dpaa2: - drop INNERMOST support entirely (reject the level), or - keep it strictly inner-only and accept it does not respect the API for plain traffic (single queue). Which of the two do you prefer? Regards, Maxime
