Multi-PHYs and multiple-ports bonding support

[Maxime Chevallier]

Hello Russell,

On Mon, 17 Oct 2022 10:24:49 +0100
"Russell King (Oracle)" <linux at armlinux.org.uk> wrote:

> On Mon, Oct 17, 2022 at 10:51:00AM +0200, Maxime Chevallier wrote:
> > 2) Changes in Phylink
> > 
> > This might be the tricky part, as we need to track several ports,
> > possibly connected to different PHYs, to get their state. For now, I
> > haven't prototyped any of this yet.  
> 
> The problem is _way_ larger than phylink. It's a fundamental
> throughout the net layer that there is one-PHY to one-MAC
> relationship. Phylink just adopts this because it is the established
> norm, and trying to fix it is rather rediculous without a use case.
> 
> See code such as the ethtool code, where the MAC and associated layers
> are# entirely bypassed with all the PHY-accessing ethtool commands and
> the commands are passed directly to phylib for the PHY registered
> against the netdev.
> 
> We do have use cases though - consider a setup such as the mcbin with
> the 3310 in SGMII mode on the fibre link and a copper PHY plugged in
> with its own PHY - a stacked PHY situation (we don't support this
> right now.) Which PHY should the MII ioctls, ethtool, and possibly the
> PTP timestamp code be accessing with a copper SFP module plugged in?
> 
> This needs to be solved for your multi-PHY case, because you need to
> deal with programming e.g. the link advertisement in both PHYs, not
> just one - and with the above model, you have no choice which PHY gets
> the call, it's always going to be the one registered with the netdev.
> 
> The point I'm making is that you're suggesting this is a phylink
> issue, but it isn't, it's a generic networking layering bypass issue.
> If the net code always forwarded the ethtool etc stuff to the MAC and
> let the MAC make appropriate decisions about how these were handled,
> then we would have a properly layered approach where each layer can
> decide how a particular interface is implemented - to cope with
> situations such as the one you describe.

I agree with all you say, and indeed this problem is a good opportunity
IMO to consider the other use-cases like the one you mention and come
up with a nice solution.

My intention was never to imply that this is a phylink issue. Quite the
contrary, what I'm saying is that phylink as it is would need to take
this into account, by extending it, with all the above-mentionned
use-cases.

When you mention that ethtool bypasses the MAC layer and talks to
phylib, since phylink has the overall view of the link, and abstracts
the phy away from the MAC, I would think this is a good place to
manage this tree of PHYs/ports, but on the other hand that's adding
quite a lot of complexity to phylink.

Maxime