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 <[email protected]> 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 |
