Re: [PATCH net-next 00/13] Introduce an ethernet port representation

[Sean Anderson <seanga2@gmail.com>]

Hi Maxime,

On 2/7/25 17:36, Maxime Chevallier wrote:
> Hello everyone,
> 
> This series follows the 2 RFC that were sent a few weeks ago :
> RFC V2: https://lore.kernel.org/netdev/20250122174252.82730-1-maxime.chevallier@bootlin.com/
> RFC V1: https://lore.kernel.org/netdev/20241220201506.2791940-1-maxime.chevallier@bootlin.com/
> 
> The goal of this series is to introduce an internal way of representing
> the "outputs" of ethernet devices, for now only focusing on PHYs.
> 
> This allows laying the groundwork for multi-port devices support (both 1
> PHY 2 ports, or more exotic setups with 2 PHYs in parallel, or MII
> multiplexers).
> 
> Compared to the RFCs, this series tries to properly support SFP,
> especially PHY-driven SFPs through special phy_ports named "serdes"
> ports. They have the particularity of outputing a generic interface,
> that feeds into another component (usually, an SFP cage and therefore an
> SFP module).
> 
> This allows getting a fairly generic PHY-driven SFP support (MAC-driven
> SFP is handled by phylink).
> 
> This series doesn't address PHY-less interfaces (bare MAC devices, MACs
> with embedded PHYs not driven by phylink, or MAC connected to optical
> SFPs) to stay within the 15 patches limit, nor does it include the uAPI
> part that exposes these ports to userspace.
> 
> I've kept the cover short, much more details can be found in the RFC
> covers.
> 
> Thanks everyone,
> 
> Maxime

Forgive me for my ignorance, but why have a new ethtool interface instead of
extending ethtool_link_settings.port? It's a rather ancient interface, but it
seems to be tackling the exact same problem as you are trying to address. Older
NICs used to have several physical connectors (e.g. BNC, MII, twisted-pair) but
only one could be used at once. This seems directly analogous to a PHY that
supports multiple "port"s but not all at once. In fact, the only missing
connector type seems to be PORT_BACKPLANE.

I can think of a few reasons why you wouldn't use PORT_*:

- It describes the NIC and not the PHY, and perhaps there is too much impedance
   mismatch?
- There is too much legacy in userspace (or in the kernel) to use that API in
   this way?
- You need more flexibility?

At the very least, I think some discussion in one of the commits would be
warranted. Perhaps there was some on the RFC that I missed?

--Sean