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

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

[D H, Siddaraju]

Hi Linux Ethernet Team,

We explored Ethtool's "10000base_CR" PMD PHY type
and we think it might be just a wrong name.

Why we called 10000Base_CR, a confusing name?
Because it fails all below 4 major highlights of a "typical base-CR"
    1. Every other Base-CR is an IEEE defined PMD specs
    2. All Base-CR have AN LT (Auto-Negotiation & Link Training)
    3. Almost all CR have FEC mandatory
    4. IEEE CR is a very close sibling of IEEE KR, the complex ones

There is NO IEEE 802.3 or ANY other standard spec to
support 10000base-CR and the industry fully adopted
SFF-8431 Appendix-E Direct Attach cable as 10G-SFI-DA.

We feel 10000Base_CR must be renamed to 10000_SFI_DA.
    SFI: SFP+ high speed serial electrical interface
    DA: Direct Attach cable media

Need your inputs for the next step here. Should we,
(a) Submit a patch to rename all instance of 10000baseCR
OR
(b) Create a new enum for SFI_DA and map it to 10000baseCR?

We prefer option-(a) since it completely resolves the confusion
and gives a technically correct name.

- Thank you,
Siddaraju D H

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

[Andrew Lunn]

On Fri, Jun 26, 2026 at 02:15:27PM +0000, D H, Siddaraju wrote:
> Hi Linux Ethernet Team,
> 
> We explored Ethtool's "10000base_CR" PMD PHY type
> and we think it might be just a wrong name.

~/linux$ grep -r 10000Base_CR
~/linux$ 

~/ethtool$ grep -r 10000Base_CR
~/ethtool$ 

What exactly do you mean by 10000Base_CR?

     Andrew

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

[Maxime Chevallier]

Hi,

On 6/26/26 16:15, D H, Siddaraju wrote:
> Hi Linux Ethernet Team,
> 
> We explored Ethtool's "10000base_CR" PMD PHY type
> and we think it might be just a wrong name.
> 
> Why we called 10000Base_CR, a confusing name?
> Because it fails all below 4 major highlights of a "typical base-CR"
>     1. Every other Base-CR is an IEEE defined PMD specs
>     2. All Base-CR have AN LT (Auto-Negotiation & Link Training)
>     3. Almost all CR have FEC mandatory
>     4. IEEE CR is a very close sibling of IEEE KR, the complex ones
> 
> There is NO IEEE 802.3 or ANY other standard spec to
> support 10000base-CR and the industry fully adopted
> SFF-8431 Appendix-E Direct Attach cable as 10G-SFI-DA.
> 
> We feel 10000Base_CR must be renamed to 10000_SFI_DA.
>     SFI: SFP+ high speed serial electrical interface
>     DA: Direct Attach cable media

Well it's too late for a rename, this is part of the userspace API
so this name is here to stay :

https://elixir.bootlin.com/linux/v7.1.1/source/include/uapi/linux/ethtool.h#L2013

This was introduced in 2016, I think we won't gain much by adding
another linkmode that's equivalent. Even if this isn't strictly
speaking the correct mode, even some vendors sell their DA cable
as 10GBaseCR cables now :/

Maxime

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

[D H, Siddaraju]

Sorry Andrew, carry-forwarded IEEE's PMD naming convention of separating media "-CR" :D. Will stick to Ethtool :).
I was referring to "ETHTOOL_LINK_MODE_10000baseCR_FULL_Full_BIT" and its associated documentations Andrew.

- Thank you,
Siddaraju D H

-----Original Message-----
From: Andrew Lunn <andrew@lunn.ch> 
Sent: Friday, June 26, 2026 8:02 PM
To: D H, Siddaraju <siddaraju.dh@intel.com>
Cc: netdev@vger.kernel.org; Das, Shubham <shubham.das@intel.com>; Chintalapalle, Balaji <balaji.chintalapalle@intel.com>; Srinivasan, Vijay <vijay.srinivasan@intel.com>
Subject: Re: the confusing 10000base_CR. Shouldn't it be 10000_SFI_DA?

On Fri, Jun 26, 2026 at 02:15:27PM +0000, D H, Siddaraju wrote:
> Hi Linux Ethernet Team,
> 
> We explored Ethtool's "10000base_CR" PMD PHY type and we think it 
> might be just a wrong name.

~/linux$ grep -r 10000Base_CR
~/linux$ 

~/ethtool$ grep -r 10000Base_CR
~/ethtool$ 

What exactly do you mean by 10000Base_CR?

     Andrew

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

[Andrew Lunn]

On Fri, Jun 26, 2026 at 06:12:15PM +0000, D H, Siddaraju wrote:
> Sorry Andrew, carry-forwarded IEEE's PMD naming convention of separating media "-CR" :D. Will stick to Ethtool :).
> I was referring to "ETHTOOL_LINK_MODE_10000baseCR_FULL_Full_BIT" and its associated documentations Andrew.

Please don't top post. And set your mail client to wrap to around 75
characters. All standard netiquette things.

It is a good idea to be specific when asking questions. Asking about
something which does not exist in the kernel just makes it a guessing
game.

As Maxime pointed out, this is uAPI, so cannot be changed.

	Andrew

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

[D H, Siddaraju]

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.

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.

- Thank you,
Siddaraju D H

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

[Maxime Chevallier]

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

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

[D H, Siddaraju]

On 6/29/26, Maxime Chevallier wrote:
>
> On 6/26/26 21:19, D H, Siddaraju wrote:
> 
> > 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 :/

Will wait for @Michal Kubecek's response about the manual page update
and as second possibility: options to update ethtool help string.

IMHO, yes the comment in ethtool.h enum definition is good
as it helps developers who use ethtool.h directly but from
ethtool app USER point-of-view, the manual page is the
first impression and ethtool --help is second. The effort here is
to help the user with a clarification, to avoid the clear confusion
with the wrong naming of 10000baseCR for all the major 4 reasons
listed in the first email of this thread. With that said, hope that
someone will also support the manual page update because
we think it is useful.

- Thank you,
Siddaraju D H

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

[Andrew Lunn]

> Will wait for @Michal Kubecek's response about the manual page update
> and as second possibility: options to update ethtool help string.
> 
> IMHO, yes the comment in ethtool.h enum definition is good
> as it helps developers who use ethtool.h directly but from
> ethtool app USER point-of-view, the manual page is the
> first impression and ethtool --help is second. The effort here is
> to help the user with a clarification, to avoid the clear confusion
> with the wrong naming of 10000baseCR

Is there confusion? git blame suggests it has been there 10 years, and
this is the first time somebody has questioned it.

I would limit changes to Documentation, man pages, help etc.

	Andrew

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

[D H, Siddaraju]

On 6/29/26, Andrew Lunn wrote,
> Is there confusion? git blame suggests it has been there 10 years,
> and this is the first time somebody has questioned it.
>
> I would limit changes to Documentation, man pages, help etc.

Yes Andrew, as summarized in the first email of this thread, there
is no standard to explicitly support 10000baseCR and it conflicts with
so many characteristics of a "typical IEEE *baseCR". Based on my internal
discussion & feedback, it seems people are using 10000baseCR
with 10G-SFI-DA cables but the question "why should I set it to 10000baseCR
while using 10G_SFI_DACables?" keeps coming back along with the subsequent
questions to seek clarity against the "IEEE *baseCR" definitions.

This is an effort to settle it down for once & all. With option-(c) it is
just to add a clarity that 10000baseCR is SFF-8431 SFP+ Direct Attach (DA)
standard with SFI interface.

- Thank you,
Siddaraju D H

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

[Michal Kubecek]

[-- Attachment #1: Type: text/plain, Size: 3328 bytes --]

On Mon, Jun 29, 2026 at 11:30:43AM GMT, Maxime Chevallier wrote:
> > 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.

The biggest problem I see here is that even if ethtool has its own link
mode tables, those are only for backward compatibility and as long as
reasonably new ethtool and kernel are in use, ethtool gets the link mode
names from kernel. There are multiple aspects:

1. The UAPI constants. These are part of kernel uAPI and ethtool just
gets a sanitized copy of kernel file. In other words, if we want any
change here (even adding a comment), it has to be done on kernel side
and ethtool gets the change on next uapi sync. Adding an alias here
would be quite simple.

2. Link mode names as shown in "ethtool <dev>" output. These are
normally retrieved from kernel via the ETH_SS_LINK_MODES string set.
In other words, if any change were desired, it would have to happen on
kernel side as well. And unless we add a specific exception to the code,
the same name is shown in both plain text and json output. (Personally
I don't think it would be a good idea to show different name in each.)

3. Link mode names that can be used in "ethtool -s" command line. These
are handled exactly the same way as names used for output. Here I could
imagine an alias implemented on ethtool side but it would have to be
hard coded in ethtool and it would only work in (new versions of)
ethtool. In general, names shown by "ethtool <dev>" should match those
expected on "ethtool -s" command line, any mismatch would be very
confusing and impractical.

4. Adding a text to ethtool(8) manual page is possible. While most of
the link mode table in the man page is (unsurprisingly) generated, it is
then reordered manually and adding a note would definitely be possible.
One just needs to be careful about the table formatting. (Yes, I'm aware
that this table has been getting out of hand for some time and I'm
thinking about ways to make it more readable and useful. Suggestions are
welcome.)

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

That would certainly be the easiest solution but as I said above, it
would be a kernel code change, ethtool would just inherit the updated
header file.

Michal

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]