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

> > > 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