On Sun, 15 Mar 2026 at 16:10, Oleksij Rempel <[email protected]> wrote: > > 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 :)
Haha, don't be! I think it's great that we have these discussions upfront! If this is overthinking, please continue to do that! :-) > > 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. 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! > > 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! > > 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. Agreed! Björn
