Folks, thanks for the elaborate discussion (accidental complexity vs
essential complexity comes to mind...)!

Maxime Chevallier [off-list ref] writes:

Hi Andrew,

quoted

quoted

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.

If I'm following Oleksij, the idea would be to have on one side the
ability to "dump" the link topology with a finer granularity so that we
can see all the different blocks (pcs, pma, pmd, etc.), how they are
chained together and who's driving them (MAC, PHY (+ phy_index), module,
etc.), and on another side commands to configure loopback on them, with
the ability to also configure traffic generators in the future, gather
stats, etc.

Another can of worms for sure, and probably too much for what Björn is
trying to achieve. It's hard to say if this is overkill or not, there's
interest in that for sure, but also quite a lot of work to do...

It's great to have these discussion as input to the first (minimal!)
series, so we can extend/build on it later.

If I try to make sense of the above discussions...

Rough agreement on:

 - Depth/ordering should be local to a component, not global across the
   whole path.
 - Cross-component ordering comes from existing infrastructure (PHY link
   topology, phy_index).
 - The current component set (MAC/PHY/MODULE) is reasonable for a first
   pass.
 - HW traffic generators and full topology dumps are interesting but out
   of scope for now (Please? ;-)).


So, maybe the next steps are:

 1. Keep the current component model (MAC/PHY/MODULE) and the
    NEAR_END/FAR_END direction (naming need to change as Maxime said).
 
 2. Add a depth (or order?) field to ETHTOOL_A_LOOPBACK_ENTRY as Jakub
    suggested, local to each component instance. This addresses the
    "multiple loopback points within one MAC" case without requiring a
    global ordering. I hope it addresses what Oleksij's switch example
    needs (multiple local loops at different depths within one
    component) *insert that screaming emoji*.
 
 3. Document the viewpoint convention clearly.
 
 4. Punt on the grand topology dump. Too much to chew.
 
 5. Don't worry about DSA CPU ports - they don't have a netif, so
    loopback doesn't apply there today. If someone adds netifs for CPU
    ports later, depth handles it.

TL;DR: Add depth, document the viewpoint convention, and ship
it^W^Winterate.

Did I get that right?


Enjoy the w/e!
Björn