On Wed, Nov 25, 2020 at 10:35:35AM +0000, Danielle Ratson wrote:

quoted

quoted

In ethtool, for speed 100G and 4 lanes for example, there are few link modes that fits:
ETHTOOL_LINK_MODE_100000baseKR4_Full_BIT
ETHTOOL_LINK_MODE_100000baseSR4_Full_BIT
ETHTOOL_LINK_MODE_100000baseCR4_Full_BIT
ETHTOOL_LINK_MODE_100000baseLR4_ER4_Full_BIT

The suggestions I have are:
1. Add a bit that for unknown media for each link (something like
ETHTOOL_LINK_MODE_100000unknown_Full_BIT). I am not sure it is even
possible or makes sense.

The number of lanes would still need to be specified. You would need at least:

ETHTOOL_LINK_MODE_100000xR2_FULL

and

ETHTOOL_LINK_MODE_100000xR4_FULL

to distinguish between PAM4 and NRZ at 100G respectively. And, there's still
the cost of maintaining a different enum to ethtool_link_mode_bit_indices.

2. Pass the link mode as bitmap.

The user only wants to specify link speed and encoding, not media. The
bitmap has the same problem to solve. Or, should user space set the bits
for all possible media types that satisfy the desired speed and encoding?
Eeek. Alternatively, the driver would need to accept any bit that implies the
desired speed and encoding, ignoring what media the bit specifies (to do
so would require maintaining a map of equivalences, yuck).

Do you see any other option?

As stated in another sub-thread, I think the encoding can be implied by the
speed if the number of lanes is a property of the port configuration. In which
case the existing ethtool interface is sufficient.

Regards,
Edwin Peer