Hello Andrew, BJörn,

On 25/02/2026 14:14, Andrew Lunn wrote:

quoted

quoted

Suddenly does something else.

Indeed!

quoted

Is this an ABI break? How do we make this reliable so implementing
more loopbacks at different levels does not change how you use
--set-loopback?

Isn't this somewhat similar to what we have with ifindex/phy_index,
but potentially unstable when modules are swapped/changed?

If you hot plug hardware, a new PHY pops into existence, i don't think
it is too unreasonable for the hot plugable parts to change ids. I
would however expect the fixed parts to keep there IDs.

That's indeed the phy index behaviour.

But here we are talking about software, a kernel upgrade/downgrade
causing the IDs to change.
 

quoted

Instead of ids, use string name and/or topology indices (e.g.
phy_index)? All three -- owner, phy_index, name tuple?

The overall approach after all these discussions sounds fine to me, I do
think that the index of the component that does the loopback needs to be
there somewhere, when relevant.

Either through a name string, or a combo of an enum indicating the
component type (MAC/PHY/Module/etc.) + its index. I think it's safe to
assume that indices will fit in u32 ?

something like :

# MAC PCS loopback
ethtool --set-loopback eth0 loc mac name pcs

# PHY id 2 PMA loopback (I'm making things up here)
ethtool --set-loopback eth0 loc phy id 2 name pma

That way we can extend that fairly easily for, say, combo-port devices
where we could select which of the port we want to loopback :)

Maxime