On Sun, 15 Mar 2026 at 16:10, Oleksij Rempel [off-list ref] wrote:

Hi Björn,

On Fri, Mar 13, 2026 at 08:11:11PM +0100, Björn Töpel wrote:

quoted

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

Sorry for overthinking :)

Haha, don't be! I think it's great that we have these discussions
upfront! If this is overthinking, please continue to do that! :-)

quoted

Maxime Chevallier [off-list ref] writes:

quoted

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.

ack

quoted

 - Cross-component ordering comes from existing infrastructure (PHY link
   topology, phy_index).

ack

quoted

 - The current component set (MAC/PHY/MODULE) is reasonable for a first
   pass.

I do not have strong opinion here.

quoted

 - HW traffic generators and full topology dumps are interesting but out
   of scope for now (Please? ;-)).

It didn't tried to push it here. My point is - image me or may be you,
will need to implement it in the next step. This components will need to
cooperate and user will need to understand the relation and/or topology.

The diagnostic is all about topology.

I hear you, and I hope this didn't come across as negative. I
definitely think we need something that we all can continue to build
on. ...and if my summary/view isn't, please holler!

quoted

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).

Probably good to document that NEAR_END/FAR_END or local/remote is
related to the viewpoint convention. Otherwise it will get confusing
with components which mount in a unusual direction (embedded worlds is
full of it :))

ACK!

quoted

 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*.

ack. I guess "depth" fits to the "viewpoint" terminology.

quoted

 3. Document the viewpoint convention clearly.

ack

quoted

 4. Punt on the grand topology dump. Too much to chew.

ack

quoted

 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.

ack

quoted

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

Did I get that right?

I'm ok with it, but maintainers will have the last word.

Agreed!
Björn