[RFC PATCH] net/dpaa2: fix RSS at inner level for non-tunnelled traffic

[Maxime Leroy]

On Thu, Jul 16, 2026 at 9:48 AM Hemant Agrawal
<hemant.agrawal at oss.nxp.com> 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 <maxime at leroys.fr> 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 <maxime at leroys.fr>
>
> 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