Re: [PATCH net-next 02/11] ethtool: Add loopback netlink UAPI definitions

[Oleksij Rempel]

Hi Björn,

On Fri, Mar 13, 2026 at 08:11:11PM +0100, Björn Töpel wrote:
> Folks, thanks for the elaborate discussion (accidental complexity vs
> essential complexity comes to mind...)!

Sorry for overthinking :)

> Maxime Chevallier <maxime.chevallier@xxxxxxxxxxx> writes:
> 
> > Hi Andrew,
> >
> >>> 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

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

ack

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

I do not have strong opinion here. 

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

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

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

>  3. Document the viewpoint convention clearly.

ack

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

ack

>  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

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

Best Regards,
Oleksij
-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |