Skip to contentSkip to conversation

Get MAC supported link modes for SFP port

DISCUSSION Baruch Siach 3 participants 5 messages Nov 26, 2020

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

Hi netdev list,

I am trying to retrieve all MAC supported link modes (ETHTOOL_LINK_MODE_*) for network interfaces with SFP port. The 'supported' bit mask that ETHTOOL_GLINKSETTINGS provides in link_mode_masks[] changes to match the SFP module that happens to be plugged in. When no SFP module is plugged, the bit mask looks meaningless.

I understand that ETHTOOL_LINK_MODE_* bits are meant to describe PHY level capabilities. So I would settle for a MAC level "supported rates" list.

Is there anything like that?

Thanks,
baruch

Signature · 3 lines
                                                     ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - [email protected] - tel: +972.52.368.4656, http://www.tkos.co.il -
#1 lore raw
Quoted 9 lines · Baruch Siach

Hi netdev list,

I am trying to retrieve all MAC supported link modes (ETHTOOL_LINK_MODE_*) for network interfaces with SFP port. The 'supported' bit mask that ETHTOOL_GLINKSETTINGS provides in link_mode_masks[] changes to match the SFP module that happens to be plugged in. When no SFP module is plugged, the bit mask looks meaningless.

Quoted 5 lines

I understand that ETHTOOL_LINK_MODE_* bits are meant to describe PHY level capabilities. So I would settle for a MAC level "supported rates" list.

Is there anything like that?

No, because there's a problem: the link modes that the MAC supports is not a particularly certain thing. When there's no module inserted, we don't know what interface mode may be in operation, and the interface mode has a big handle in determining which link modes can be supported.

For example, if it's operating as 1000BASE-X or 10GBASE-R, then we're pretty limited to a single link mode if there's nothing else present. If it's in SGMII, then 10/100/1000 speeds are possible but there's no link mode to describe that - no PHY, therefore there's no copper and therefore BASE-T is meaningless.

The ethtool link modes are, in reality, _media_ link modes. If there is no media or socket that defines the media, there are no link modes.

Signature · 2 lines
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
#2 lore raw
In reply to Baruch Siach
Quoted 8 lines · Baruch Siach

Hi netdev list,

I am trying to retrieve all MAC supported link modes (ETHTOOL_LINK_MODE_*) for network interfaces with SFP port. The 'supported' bit mask that ETHTOOL_GLINKSETTINGS provides in link_mode_masks[] changes to match the SFP module that happens to be plugged in. When no SFP module is plugged, the bit mask looks meaningless.

That sounds like it is doing the correct thing.

Quoted 3 lines

I understand that ETHTOOL_LINK_MODE_* bits are meant to describe PHY level capabilities. So I would settle for a MAC level "supported rates" list.

What is your use cases?

A MAC without some form a PHY, be it copper, fibre, or a faked fixed-link, is useless. You need the combination of what the MAC can do and what the PHY can do to have any meaning information.

Andrew

#3 lore raw

Hi Andrew,

Quoted 8 lines · Andrew Lunn
Quoted 6 lines · Baruch Siach

I am trying to retrieve all MAC supported link modes (ETHTOOL_LINK_MODE_*) for network interfaces with SFP port. The 'supported' bit mask that ETHTOOL_GLINKSETTINGS provides in link_mode_masks[] changes to match the SFP module that happens to be plugged in. When no SFP module is plugged, the bit mask looks meaningless.

Quoted 7 lines

That sounds like it is doing the correct thing.

Quoted 3 lines

I understand that ETHTOOL_LINK_MODE_* bits are meant to describe PHY level capabilities. So I would settle for a MAC level "supported rates" list.

What is your use cases?

I would like to report the port supported data rates to the system user. I need to tell whether 10Gbps SFP module are supported in that port in a generic way. The driver has this information. It is necessary to implement the validate callback in phylink_mac_ops. But I see no way to read this information from userspace.

Quoted 3 lines

A MAC without some form a PHY, be it copper, fibre, or a faked fixed-link, is useless. You need the combination of what the MAC can do and what the PHY can do to have any meaning information.

I understand that. I probably need a higher level concept of data rate supported.

baruch

Signature · 3 lines
                                                     ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - [email protected] - tel: +972.52.368.4656, http://www.tkos.co.il -
#4 lore raw
Quoted 17 lines · Baruch Siach

Hi Andrew,

Quoted 14 lines · Andrew Lunn
Quoted 6 lines · Baruch Siach

I am trying to retrieve all MAC supported link modes (ETHTOOL_LINK_MODE_*) for network interfaces with SFP port. The 'supported' bit mask that ETHTOOL_GLINKSETTINGS provides in link_mode_masks[] changes to match the SFP module that happens to be plugged in. When no SFP module is plugged, the bit mask looks meaningless.

That sounds like it is doing the correct thing.

Quoted 3 lines

I understand that ETHTOOL_LINK_MODE_* bits are meant to describe PHY level capabilities. So I would settle for a MAC level "supported rates" list.

Quoted 7 lines
Quoted 1 line

What is your use cases?

I would like to report the port supported data rates to the system user. I need to tell whether 10Gbps SFP module are supported in that port in a generic way. The driver has this information. It is necessary to implement the validate callback in phylink_mac_ops. But I see no way to read this information from userspace.

If we want to know whether 10Gbps SFPs are supported in a cage, and that information is important, we really ought to use a different DT compatible for it. I've debated about using "sff,sfp+" since that's what they are - but I have no use practical for it, so I've not made the change.

This is especially important as there are boards out there (Macchiatobin) where the SFP+ sockets do not support SFP modules from the electrical point of view, and if you happen to plug in a SFP module, you may end up with its EEPROM being corrupted merely as a result of plugging the module in and the ID trying to be read.

Signature · 2 lines
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!