Folks, thanks for the elaborate discussion (accidental complexity vs essential complexity comes to mind...)!
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. - 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
