> As for me, it is problematic to help the user to understand the datapath
> depth on a switch. For example:
Do you mean Ethernet switch? Or MII switch.
>
> CPU -- xMII --- MAC1 [loop] --- fabric --- MAC2 [loop] --- xMII -- PHY
> \----- MACx [loop] ---
In DSA, MAC1 is the CPU port of the switch. It is not represented by a
netif. Since there is no netif, you cannot use ethtool on it. So it is
impossible to apply loopback here.
This is one of the oddities of DSA. The CPU port and the conduit
interface on the host are just plumbing to make the setup work. In
terms of networking, they are not important. But sometimes you need to
get into the plumbing to find out why it is blocked up, statistics are
useful, and maybe loopback as well. We have discussed it a few times
that MAC1 should have a netif, but the conclusion is that developers
have a hard enough time with the conduit interface, adding yet another
oddball interface with no real purpose other than diagnostics is gone
to make the confusion even worse.
So i don't think depth is relevant here.
> ... each port has two xMII loop configurations: towards the xMII or towards
> the fabric. From a driver perspective, a loop towards the xMII is
> "remote." However, from a system perspective, a "remote" loop on MAC1 is
> a local loop at depth=0, whereas a "local" loop on MAC2 is a local loop
> at depth=1.
If you think about DSA and the Linux representation, the switch fabric
is not seen at all. All you have are user ports, those going to the
outside world. They act the same as interfaces directly connected to
the SoC. So "remote" and "local" must have the same meaning as an
interface directly connected to the host. And this is true for
switchdev in general, DSA is not special in any way.
> One more issue is the test data generator location. The data generator
> is not always the CPU. We have HW generators located in components like
> PHYs or we may use external source (remote loopback).
At the moment, we don't have a Linux model for such generators. There
is interest in them, but nobody has actually stepped up and proposed
anything. I do see there is an intersect, we need to be able to
represent them in the topology, and know which way they are pointing,
but i don't think they have a direct influence on loopback.
Andrew
