Issue with DPAA2 DPDMUX Reconfiguring DPNI MAC Address

[RaRiRu]

I am writing to report an issue I am experiencing with the DPAA2 mux (DPDMUX) driver regarding the MAC address configuration of a DPNI when it is attached as a port to a DPDMUX.

Issue Description

In our setup, the MAC addresses for the DPNI objects are statically defined in a dpc.dts file. My expectation is that when a DPNI is connected as a port to a DPDMUX, it retains the MAC address assigned in the dpc.dts. However, upon connecting a DPNI to the DPDMUX (using a custom configuration), I observe that the DPNI’s MAC address is reconfigured by the MC firmware. This unexpected change causes issues downstream (e.g., when matching flows and for overall network behavior).

Our Setup

• Configuration:

• The dpc.dts file includes static MAC addresses for all DPNI objects.
• The DPDMUX is created with the following parameters (manually emitted via restool commands):

• Method: DPDMUX_METHOD_CUSTOM
• Manipulation: DPDMUX_MANIP_NONE
• Options: DPDMUX_OPT_CLS_MASK_SUPPORT
• Number of Interfaces: 2
• Default Interface: 1

• I disconnect dpni.8 from dprc.6, create the DPDMUX, and connect:

• dpdmux.0.0 → dpmac.3 (uplink)
• dpdmux.0.1 → dpni.7
• dpdmux.0.2 → dpni.8

• After these connections, the DPDMUX object is assigned to the DPRC (dprc.6) and the DPRC is rebound to VFIO.

Observations

After these operations, the MAC address of dpni.8 (as defined in our dpc.dts) is changed by the DPDMUX configuration process. I anticipated that the DPNI’s MAC address would remain as specified in the device tree, but instead it is reprogrammed. This reconfiguration interferes with my ability to correctly match flows and manage traffic as expected.

Request for Assistance

Could you please advise if:

• This behavior is expected due to DPAA2/DPDMUX internal bridging requirements?
• There is a way to preserve the DPNI MAC address as defined in the dpc.dts (perhaps via a specific configuration flag or by altering the DPDMUX method/parameters)?
• A post-connection reprogramming step (or a workaround in the driver) might be advisable to restore the original MAC address?

Additional question regarding the static configuration of a DPDMUX in the dpl.dts file

One more question and a very important one: is there any example available, which shows how to statically configure in a dpl.dts file a dpdmux correctly?
We are trying to do it already but cannot manage it to work. The static configuration we are looking for should/can equivalent to the following sequence of restool-commands like found at https://docs.nxp.com/bundle/GUID-487B2E69-BB19-42CB-AC38-7EF18C0FE3AE/page/GUID-33CD3951-762C-4230-B...:

# Unbinding dprc.2 from VFIO
echo dprc.2 > /sys/bus/fsl-mc/drivers/vfio-fsl-mc/unbind
# Remove dpni.2 from dprc.2 so that it can be assigned to dpdmux
restool dprc disconnect dprc.2 --endpoint=dpni.1
# Create dpdmux with CUSTOM flow creation; Flows would be created
# from the Userspace (DPDK) application
restool dpdmux create --default-if=1 --num-ifs=2 --method DPDMUX_METHOD_CUSTOM --
manip=DPDMUX_MANIP_NONE --option=DPDMUX_OPT_CLS_MASK_SUPPORT --container=dprc.1
# Create DPDMUX with two DPNI connections and one DPMAC connection
restool dprc connect dprc.1 --endpoint1=dpdmux.0.0 --endpoint2=dpmac.5
restool dprc connect dprc.1 --endpoint1=dpdmux.0.1 --endpoint2=dpni.3
restool dprc connect dprc.1 --endpoint1=dpdmux.0.2 --endpoint2=dpni.1
restool dprc assign dprc.1 --object=dpdmux.0 --child=dprc.2 --plugged=1 

Further, do we need to load in defconfig the "evb" driver to make thinks working? The evb-driver's specific source is located in linuq-qoriq/drivers/staging/fsl-dpaa2/evb.

Thank you very much for your time and assistance.

[RaRiRu]

Is anything unclear to the issue I have described? If necessary, I may provide additional information on this topic.

[yipingwang]

All the traffic from dpdmux endpoints is actually from single dpmac physically, so it does make sense that all dpnis connected to dpdmux share same MAC address. The traffic split to different endpoints depends on flow applied on dpdmux which are generally identified by L3 or L4 layers but not MAC address.

Dpdmux utilization doesn’t rely on any Linux component something like evb you mentioned. Just follow up NXP dpdk guide.

[RaRiRu]

Hi,

Thank you for your response.

After a deeper analysis, we found that the current dpaa2-eth driver does not support the configuration where a DPNI is connected to a DPDMUX rather than directly to a DPMAC. Specifically, if the driver detects that a DPNI is not connected to a DPMAC, it fails to retrieve the MAC address via the dpni_get_port_mac_address() command and then falls back to assigning a random MAC address to the network interface.

To resolve this, we have patched the dpaa2-eth driver. Our changes are as follows:

1. During probe, the driver now checks whether the probed DPNI has an endpoint of type DPDMUX.

2. If a DPDMUX endpoint is found, the driver queries the DPDMUX’s uplink endpoint (which is always connected to a DPMAC).

3. It then issues the DPMAC_GET_MAC_ADDR command to retrieve the MAC address from the DPMAC (as defined in the DPC.dts file).

4. Finally, the retrieved MAC address is assigned to the network interface instead of a random MAC.

This modification ensures that for DPDMUX-connected DPNIs, the network interface gets the correct MAC address from the associated DPMAC, rather than a randomly generated one.