Re: Ethtool is missing C2C link modes

[Andrew Lunn <andrew@lunn.ch>]

> Siddaraju: baseR is an end-to-end physical layer type that clearly defines
> 	the	interface & components stating from MAC RS(Reconciliation Sublayer)
> 	till the PMD + MDI signallings. AUI is an intermediate electrical interface
> 	layer(simplified KR) that connects 2 PMAs (PMA <=== AUI ===> PMA).
> 	AUI is a split function design approach where subfunction implementation
> 	from multiple vendors come together to exploit their domain expertise
> 	to produce a best Ethernet interconnect.

> Andrew: I _think_ ethtool reports the media, not some intermediary format.
> 	Is ETHTOOL_LINK_MODE_25000baseC2C_Full_BIT actually needed? 
> Siddaraju: We are here to find out that Andrew :).
> 	If we are following the strict convention that ethtool link modes
> 	report & represents the end-to-end flow "ONLY", then yes, AUI doesn't
> 	fit there. We are exploring phy_interface_t for intermediate interfaces
> 	and we hope we don't hit any roadblocks. Let's see.

Given these two answer, phy_interface_t is a better fit. I'm however
not sure it is fully correct. Historically, it was used to indicate
the interface between the MAC and base-T PHYs. PCS and PMD either did
not exist, or was an invisible layer, back in those days. At that
point phy_interface_t was the bottom of the reconciliation layer?

The introduction of SGMII and 1000BaseX made PCS a thing, even if
initially it was generally hidden away. PHY_INTERFACE_MODE_SGMII then
corresponds to the bottom of the PCS, with the Base-T PHY also talking
SGMII. phy_interface_t then moves from the reconciliation layer to a
lower layer?

So what exactly does phy_interface_t mean?

And historically, we have only had a single phy_interface_t value. Are
there use cases for needing different C2C values are different layers?
Could you have a single lane 100G C2C split into 4 lanes of 25G C2C?

Another thing we should consider. Most NICs above 10G currently don't
have Linux controlling the hardware. These lower layers are all hidden
away in firmware. For you hardware, is Linux actually controlling any
of this?  Are you adding support to phylink for these intermediary
building blocks? Should Linux currently care about C2C?

	Andrew