Message-ID: <c927247b-e39c-8511-d95c-77fb23b82808@gmail.com>
Date: Wed, 12 Feb 2025 10:39:48 -0500
From: Sean Anderson <seanga2@...il.com>
To: Maxime Chevallier <maxime.chevallier@...tlin.com>
Cc: davem@...emloft.net, netdev@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
 thomas.petazzoni@...tlin.com, Andrew Lunn <andrew@...n.ch>,
 Jakub Kicinski <kuba@...nel.org>, Eric Dumazet <edumazet@...gle.com>,
 Paolo Abeni <pabeni@...hat.com>, Russell King <linux@...linux.org.uk>,
 linux-arm-kernel@...ts.infradead.org,
 Christophe Leroy <christophe.leroy@...roup.eu>,
 Herve Codina <herve.codina@...tlin.com>,
 Florian Fainelli <f.fainelli@...il.com>,
 Heiner Kallweit <hkallweit1@...il.com>,
 Vladimir Oltean <vladimir.oltean@....com>,
 Köry Maincent <kory.maincent@...tlin.com>,
 Marek Behún <kabel@...nel.org>,
 Oleksij Rempel <o.rempel@...gutronix.de>,
 Nicolò Veronese <nicveronese@...il.com>,
 Simon Horman <horms@...nel.org>, mwojtas@...omium.org,
 Antoine Tenart <atenart@...nel.org>, devicetree@...r.kernel.org,
 Conor Dooley <conor+dt@...nel.org>, Krzysztof Kozlowski
 <krzk+dt@...nel.org>, Rob Herring <robh@...nel.org>,
 Romain Gantois <romain.gantois@...tlin.com>
Subject: Re: [PATCH net-next 00/13] Introduce an ethernet port representation

Hi Maxime,

On 2/10/25 03:55, Maxime Chevallier wrote:
> Hi Sean,
> 
> On Fri, 7 Feb 2025 21:14:32 -0500
> Sean Anderson <seanga2@...il.com> wrote:
> 
>> 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?
> 
> So there are multiple reasons that make the PORT_* field limited :
> 
>   - We can't gracefully handle multi-port PHYs for complex scenarios
> where we could say "I'm currently using the Copper port, but does the
> Fiber port has link ?"
> 
>   - As you mention in your first argument, what I'd like to try to do is
> come-up with a "generic" representation of outgoing NIC interfaces. The
> final use-cases I'd like to cover are multi-port NICs, allowing
> userspace to control which physical interfaces are available, and which
> t use. Looking at the hardware, this can be implemented in multiple
> ways :
> 
>             ___ Copper
>            /
>   MAC - PHY
>            \__ SFP
> 
> Here, a single PHY has 2 media-side interfaces, and we'd like to select
> the one to use. That's fairly common now, there are quite a number of
> PHYs that support this : mv33x3310, VSC8552, mv88x2222 only to name a
> few. But there are other, more uncommon topologies that exist :
> 
>                             ____ SGMII PHY -- Copper
>                            /
>   MAC - SGMII/1000BaseX MUX
>                            \____ SFP
> 
> Here, we also have 2 media-side ports, but they are driver through
> different entities : The Copper port sits behind a single-port PHY,
> that is itself behind a *MII MUX, that's also connected to an SFP. Here
> the port selection is done at the MUX level
> 
> Finally, I've been working on supporting devices whith another topology
> (actually, what started this whole work) :
> 
>              ___ PHY
>             /
>   MAC --MUX |
>             \__ PHY
> 
> Here both PHYs are on the same *MII bus, with some physical,
> gpio-driven MUX, and we have 2 PORT_TP on the same NIC. That design is
> used for link redundancy, if one PHY loses the link, we switch to the
> other one (that hopefully has link).
> 
> All these cases have different drivers involved in the MUX'ing (phy
> driver itself, intermediate MUX in-between...), so the end-goal would
> be to expose to userspace info about the media interfaces themselves.
> 
> This phy_port object would be what we expose to userspace. One missing
> step in this series is adding control on the ports (netlink API,
> enabling/disabling logic for ports) but that far exceeds the 15 patches
> limitation :)
> 
> Sorry if all of that was blurry, I did make so good of a job linking to
> all previous discussions on the topic, I'll address that for the next
> round.

Thanks for the detailed explanation, especially regarding PHY redundancy.
Could you add it to a commit message (or even better to Documentation/)?

--Sean

Powered by blists - more mailing lists