Re: ethtool settings and SFP modules with PHYs

[Maxime Chevallier]

Hi,

On Mon, 16 Sep 2024 18:34:59 +0100
"Russell King (Oracle)" <linux@xxxxxxxxxxxxxxx> wrote:

[...]

> The best place to decide to notify userspace would be at the
> module_start() callback - this happens when a module is present,
> and the netdev has been brought up. Note that this call will happen
> each and every time the netdev is brought up.

As we are brainstorming, may I suggest an alternative approach ?

I'm currently working on getting some way of providing userspace with a
representation of the front-facing ports of a netdev. This would
include SFP module ports, RJ45/8P8C/BaseT ports, BaseT1 ports, you name
it.

This would allow to represent with a bit more clarity use-cases such as
the MCBin's ports controlled by the 88x3310, the combo RJ45 / SFP ports.

The other case would be devices which have several PHYs in parallel.

The way I see it for now, is that we would have internal kernel objects
with a name such as "phy_port" or "phy_mdi" or just "mdi" (I'm bad at
naming), instanciated by PHY drivers (or phylib through generic helpers
in most simple case for single-port PHYs), as well as the SFP
subsystem, but also by NICs that have a front-facing port that's driven
neither through SFPs nor PHYs (through a firmware of some sort).

These phy_port would have a set of callback ops to get their
ethtool_ksettings linkmodes and could be added/removed dynamically, in
the case of SFP module insertion for example.

The notification I would imagine would be "there's a change on the
front-facing port" or "there's a new one, here's what it can do" in the
case of module insertion.

I already have some code for that, and I will talk about this exact
topic tomorrow morning at the networking track of LPC [1]

For the SFP case, the notification would trigger indeed at the
module_start/module_remove step.

All of that is still WIP, but I think it would reply to that exact need
of "notifying users when something happens to the ports", including SFP
module insertion.

I plan to submit an RFC shortly after LPC, I still need to iron some
things out, and I think that RFC will itself trigger a lot of
discussions, but do you see that this kind of work could help resolving
the issue faced by Daniel as well as the need for SFP-event
notifications ?

Thanks,

Maxime

[1] : https://lpc.events/event/18/contributions/1964/