2399177_en-US

是

DPAA2 DPDK RSS Hash on MPLS Inner IP

Hello,

I'm testing DPAA2 RSS capabilities with DPDK on a SolidRun LX2160A Clearfog CX.
I've found that it is able to hash on MPLS labels and PPPoE inner IP for example.
However it seems to not be able to hash on MPLS inner IP, am I right on this ?
This surprise me a bit because:
- It know what is a MPLS header because it is able to hash on MPLS labels
- It know how to get inner IP because it is able to hash on PPPoE inner IP

Could you confirm if it is supported or not to hash on MPLS inner IP ?

I'm quite newbie with NXP DPAA2 and NXP in general, so can you please explain your technical words.

Thanks.

Re: DPAA2 DPDK RSS Hash on MPLS Inner IP

Yes — your understanding is correct for the DPDK DPAA2 PMD as used from testpmd today : hashing on the MPLS label itself is supported, and hashing on inner IP after PPPoE can work, but MPLS inner IP RSS is not clearly exposed as a ready-to-use DPDK RSS mode .

The important nuance is this:

DPAA2 hardware is capable enough : the LX2160A parser can recognize MPLS, walk through an MPLS label stack, and then continue parsing to IPv4/IPv6 under some conditions.
DPAA2 key extraction also has “inner/last IP” fields : the distribution key mechanism can use HDR_INDEX = 0xFF , meaning “most inner / last header,” and the hardware defines IPSRC_N / IPDST_N for the last IP header.
But the public DPDK DPAA2 PMD documentation only says RSS is supported in general , and lists limitations like fixed RSS key and non-configurable RETA; it does notas a supported RSS combination. The Linux/SDK-facing hashing documentation lists ordinary fields such as Ethernet destination, VLAN, L3 protocol, IPv4 source/destination, and L4 ports, but not “IP after MPLS” as a selectable hash mode.

So: not a silicon limitation, but likely a software/driver exposure limitation in the DPDK DPAA2 PMD path you are using.

What you can try

First confirm that DPAA2 sees the packet as “MPLS + inner IP”

If the hardware parser does not mark the inner IPv4 header as present, RSS on inner IP cannot work.

In DPDK, enable DPAA2 PMD logs:

Copy

--log-level=pmd.net.dpaa2:debug

Also check whether received packets get meaningful packet type information in your application or with testpmd , for example whether packets are classified only as MPLS or as MPLS plus inner IPv4.

If the packet type stops at MPLS, the RSS hash cannot use inner IPv4 because, from the driver’s point of view, inner IPv4 was not parsed.

Try being explicit in the flow pattern

If you only configured RSS type mpls , that will naturally hash MPLS fields. Try a pattern that explicitly includes the inner IPv4 header:

Copy

flow create 0 ingress \

pattern eth / mpls / ipv4 / end \

actions rss queues 0 1 end types ipv4 end / end

If you want source/destination IP specifically, also try:

Copy

flow create 0 ingress \

pattern eth / mpls / ipv4 / end \

actions rss queues 0 1 end types ip ipv4 end / end

If that is rejected or accepted but still does not distribute based on the inner IPv4 addresses, then the PMD is probably not programming the DPAA2 distribution key as “last/inner IP.”

Try MPLS label values that help the parser

If your MPLS traffic uses ordinary service labels, the parser may not know the payload is IPv4. For a controlled test, try MPLS Explicit NULL labels:

MPLS label 0 means IPv4 Explicit NULL.
MPLS label 2 means IPv6 Explicit NULL.

The DPAA2 documentation says label 0 maps to IPv4 and label 2 maps to IPv6 when MPLS label interpretation is enabled .

If RSS on inner IP works only with label 0 , then the problem is not RSS itself; the issue is that the parser was not being told that your MPLS payload is IP.

If you need this feature, the real fix is likely PMD work

The DPAA2 hardware has the concepts needed for this:

HDR_INDEX = 0xFF means “use the most inner header”.
IPSRC_N and IPDST_N are the source/destination address of the last IP header.
The MPLS parser can advance beyond MPLS to IP when configured appropriately.

So a driver-level implementation would likely need to program the DPNI distribution profile to extract:

inner/last IPv4 source address,
inner/last IPv4 destination address,
possibly inner L4 ports,
after an MPLS parse path.

In practical terms: this may require changing the DPAA2 DPDK PMD , not just changing a testpmd command.

My conclusion: DPAA2 hardware can in principle reach “inner/last IP” fields, but MPLS-inner-IP RSS does not appear to be a ready-supported DPDK DPAA2 PMD feature on your stack; if explicit eth / mpls / ipv4 RSS rules fail, the likely solution is a PMD/parser/distribution-profile change rather than a different testpmd command.