Created attachment 845701 [details]
systemd patch

Attached is a draft patch implementing a new mode NET_DPAA2 and name scheme [en]dX (d as in DPAA2; p and a are taken) based on dpni.X sysfs dir name.

This upstream patch applies cleanly to our Base:System systemd package and has been tested on Ten64 by installing the modified udev package and rebooting.

https://build.opensuse.org/package/show/home:a_faerber:branches:Base:System/systemd

Does it make sense to extend my scheme with the dprc.Y number, such as dYiX?
On Ten64 there was only dprc.1, and other schemes omit common numbers such as 0.

Do any DPAA2 platforms today support multi-socket configurations, where there could be more than one DPAA2 complex within one system? We could use DZdX then for socket Z >0 and simplified dX for socket 0.

Can this name scheme also cover DPAA1 and should be renamed to NET_DPAA etc.?
Didn't have any DPAA1 devices myself for testing.

One downside of my initial implementation based on available sysfs data is that on Ten64 board the DPNI numbers do not correspond to chassis port numbers. Its config appears to rather align 1-based DPMAC numbers to 0-based port numbers, which then match ethX numbers today (if they don't collide with USB - PCIe being enPXpY.../enpY, and the USB scheme not being applied to non-PCIe controllers).
So either one would need two DPAA2 configs for new systemd vs. legacy systems, or we would need to implement both path and slot schemes, one using DPNI (dYiX), the other using DPMAC (dYmZ) - which would require exposing the DPMAC numbers in sysfs somehow.

Independently some generic way to make them [en]o0..9 based on Device Tree data or [en]GE0..7/XG0..1 based on labels could help for such on-board ports.

> Attached is a draft patch implementing a new mode NET_DPAA2 and name scheme [en]dX (d as in DPAA2; p and a are taken) based on dpni.X sysfs dir name.
> 
> This upstream patch applies cleanly to our Base:System systemd package and has been tested on Ten64 by installing the modified udev package and rebooting.
> 
> https://build.opensuse.org/package/show/home:a_faerber:branches:Base:System/systemd
> 
> Does it make sense to extend my scheme with the dprc.Y number, such as dYiX?
> On Ten64 there was only dprc.1, and other schemes omit common numbers such as 0.
> 
> Do any DPAA2 platforms today support multi-socket configurations, where there could be more than one DPAA2 complex within one system? We could use DZdX then for socket Z >0 and simplified dX for socket 0.
> 
> Can this name scheme also cover DPAA1 and should be renamed to NET_DPAA etc.?
> Didn't have any DPAA1 devices myself for testing.

There is no fsl-mc bus concept on DPAA1 based systems, so this will only work for DPAA2.

> 
> One downside of my initial implementation based on available sysfs data is that on Ten64 board the DPNI numbers do not correspond to chassis port numbers. Its config appears to rather align 1-based DPMAC numbers to 0-based port numbers,
 which then match ethX numbers today (if they don't collide with USB - PCIe being enPXpY.../enpY, and the USB scheme not being applied to non-PCIe controllers).
> So either one would need two DPAA2 configs for new systemd vs. legacy systems, or we would need to implement both path and slot schemes, one using DPNI (dYiX), the other using DPMAC (dYmZ) - which would require exposing the DPMAC number
s in sysfs somehow.

We could expose the DPMAC numbers in the 'phys_port_name' sysfs but this will not really solve the problem.

> 
> Independently some generic way to make them [en]o0..9 based on Device Tree data or [en]GE0..7/XG0..1 based on labels could help for such on-board ports.

That would help even more since different boards have different labels for the same MAC.

The DSA subsystem has a naming scheme based on the labels found in the DTS node of a specific switch port.
This solution doesn't go through udev rules but rather the DSA core assigns at probe time a name for the net_device based on the label found in the DTS.

I would much rather prefer this approach since it solves the problem in a much generic way. I could go ahead and send some patches to net-next if you find it useful as well.

> Does it make sense to extend my scheme with the dprc.Y number, such as dYiX?
On Ten64 there was only dprc.1, and other schemes omit common numbers such as 0.

Multiple DPRCs are generally only used when an IOMMU boundary is needed, e.g for VFIO passthrough of fsl-mc objects or special applications like DPDK.

For the VFIO case, the child VM will see it's objects under dprc.X (where X != 0, the top level container). Unlike PCIe-VFIO the child VM operates under the same 'namespace' as the parent (with access control enforced by the MC firmware).

I don't think it would be a good idea to do consistent naming based on DPRC as the DPRC allocation may change from the host side.

Here is one example of a non-0 dprc (VM using a passthrough DPNI):
udevadm info /sys/class/net/eth0
P: /devices/platform/4040000000.fsl-mc/dprc.2/dpni.2/net/eth0
L: 0
E: DEVPATH=/devices/platform/4040000000.fsl-mc/dprc.2/dpni.2/net/eth0
E: INTERFACE=eth0

> Do any DPAA2 platforms today support multi-socket configurations, where there could be more than one DPAA2 complex within one system? We could use DZdX then for socket Z >0 and simplified dX for socket 0.

Some QorIQ PowerPC SoCs (e.g T4240) had multiple ethernet "controllers" (FMan's) (due to throughput limitations?) but I doubt there would be a need/desire to have multiple DPAA2 complex/MC buses on the same system, the value proposition with these SoCs is to keep everything on the same 'dataplane' to maximize the hardware offload capabilities.

> Upstream udev appears to support NET_PLATFORM devices on arm64 with ACPI only; no naming scheme seems defined or implemented for Device Tree, and Ten64's Device Tree does not appear to define any Ethernet aliases either.

Would there be a case for bringing ACPI's consistent network device naming to device tree? This isn't confined to DPAA2, it can happen on any system where the 'logical' order of MACs is not the same as the physical order.

We had a bigger problem with this on the LS1043, as the internal MACs were numbered (in order of physical port) 1,2,5,6,3,9. (and the first four were hanging off the same QSGMII/Quad-PHY which made it more annoying!)

Ten64 (and LS1088ARDB) the corresponding MACs are (from GE0->XG1) 7,8,9,10,3,4,5,6,2,1

On the Ten64 I exploited the fact that DPNIs will be enumerated in a consistent fashion based on how they are connected in the DPC file:

https://gitlab.com/traversetech/ls1088firmware/firmware-builder/-/blob/phylink_test/dpaa2/dpl/eth-dpl-all.dts#L776

IIRC the "reverse" DPNI order is because of that.

A method to mark up 'chassis names' in device tree would be nice for the above reasons.

For DPAA2 we would want to do this on the DPMAC level and for that information to be propagated to the DPNI I think?