Re: the confusing 10000base_CR. Shouldn't it be 10000_SFI_DA?

[Maxime Chevallier <maxime.chevallier@bootlin.com>]

Hi,

+Michal

On 6/26/26 21:19, D H, Siddaraju wrote:
> Sure, thanks for pointing them, Andrew, will follow.
> Now I realized what you meant there, thank you for the quick feedback.
> 
> About options,
> Ok, got it: "option-(a): renaming *10000baseCR*" is out.
>   Sure, will support this from uAPI backward-compatibility point-of-view.
> 
>   Just to highlight Maxime, yes during exploration, we too came across
>   those few vendor products. But when we looked further to understand
>   which standard those 10GBaseCR cables were following, we found they all
>   explicitly call out that its SFP+ DA conforming to SFF-8431.
> 
> What about
> "option-(b): create a new enum ETHTOOL_LINK_MODE_10G_SFI_DA_Full_BIT"?
>   Idea is just to create a new enum, with same enum value of 10000baseCR.
>   This will NOT consume a bit position in "ethtool_link_mode_bit_indices".
>   It just helps those tech-savvy people, who does not accept 10000baseCR
>   and prefer 10000sfiDA for being explicit.

The thing is that even with a new enum value, that won't bring much to
the table. It would likely be better to have a comment near the
10000baseCR definition explaining the SFF equivalency.

> 
> At worst case, hope we agree for
> "option-(c): ethtool.8 man page help strings to indicate 10G_SFI_DA"
>   Something like
>     "10000baseCR (10G_SFI_DA    SFF-8431 SFP+ DA)
>   under "advertise" mask values.

In that case, let's add Michal in the loop as the ethtool maintainer. Even
then it's not straightforward as some tooling relies on the JSON output
from ethtool, so _if_ we change the output for that mode, it should only
be in the non-json output.

My personal opinion would be that adding a comment in the enum definition
near 10000baseCR is enough :/

Maxime