linux-kernel - Re: [PATCH] net: sfp: handle 100G/25G active optical cables in sfp_parse

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <ZNTShohLvCQR5AlU@shell.armlinux.org.uk>
Date:   Thu, 10 Aug 2023 13:05:26 +0100
From:   "Russell King (Oracle)" <linux@...linux.org.uk>
To:     Josua Mayer <josua@...id-run.com>
Cc:     netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        Andrew Lunn <andrew@...n.ch>,
        Heiner Kallweit <hkallweit1@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>
Subject: Re: [PATCH] net: sfp: handle 100G/25G active optical cables in
 sfp_parse_support

On Thu, Aug 10, 2023 at 01:38:13PM +0200, Josua Mayer wrote:
> Hi Russell,
> 
> Am 10.08.23 um 12:39 schrieb Russell King (Oracle):
> > On Thu, Aug 10, 2023 at 11:48:17AM +0200, Josua Mayer wrote:
> > > Handle extended compliance code 0x1 (SFF8024_ECC_100G_25GAUI_C2M_AOC)
> > > for active optical cables supporting 25G and 100G speeds.
> > Thanks. I think I would like one extra change:
> > 
> > > +	case SFF8024_ECC_100G_25GAUI_C2M_AOC:
> > >   	case SFF8024_ECC_100GBASE_SR4_25GBASE_SR:
> > >   		phylink_set(modes, 100000baseSR4_Full);
> > Since SFPs are single lane, SR4 doesn't make sense (which requires
> > four lanes), and I shouldn't have added it when adding these modes.
> > It would be a good idea to drop that, or at least for the
> > addition of the SFF8024_ECC_100G_25GAUI_C2M_AOC case.
> > 
> Would it be okay changing 100000baseSR4 to 100000baseSR dropping the "4"?

Not for SFF8024_ECC_100GBASE_SR4_25GBASE_SR. SFF-8024 states for this
code:

         02h        100GBASE-SR4 or 25GBASE-SR

100GBASE-SR4: IEEE 802.3 Physical Layer specification for 100 Gb/s using
100GBASE-R encoding over four lanes of multimode fiber, with reach
up to at least 100 m. (See IEEE Std 802.3, Clause 95.)

100GBASE-R encoding: The physical coding sublayer encoding defined in
Clause 82 for 100 Gb/s operation. (See IEEE Std 802.3, Clause 82.)

25GBASE-SR: IEEE 802.3 Physical Layer specification for 25 Gb/s using
25GBASE-R encoding over multimode fiber. (See IEEE Std 802.3, Clause 112.)

IEEE 802.3-2018 doesn't define 100GBASE-SR, so I assume that's a later
development, which would be 100GBASE-R encoding over one lane of fiber.

So, 100GBASE-SR and 100GBASE-SR4 are not equivalent, and since
SFF8024_ECC_100GBASE_SR4_25GBASE_SR specifies 100GBASE-SR4, that
being _four_ lanes of fiber, and SFP form-factor modules only being
capable of carrying a single lane, and sfp-bus.c only being for SFP
modules, 100GBASE-SR4 is just not relevant for our purposes in
sfp-bus.c - and it makes no sense to switch to 100GBASE-SR because
that is not what this code tells us.

For the SFF8024_ECC_100G_25GAUI_C2M_AOC in a SFP28 module, the SFP28
form factor only supports up to 28Gb/s, so that means the module is
definitely 25GBASE-R ethernet. So that also excludes 100G operation.

So, until we see a module in the SFP form factor (implying a single
lane) that does operate at 100G speeds, I think we should omit it.

I'm also wondering whether we should check br_nom/br_max/br_min now,
so that if we have to check that in the future, we don't start causing
regressions. Knowing how module EEPROMs are randomly wrong, it would
be a good idea to start with something sensible and see whether any
fail. Bear in mind that br_nom doesn't always get set to the correct
value - for example, 1G operates at 1250Mbps, and the SFP MSA specifies
that br_nom should be 1300 for 1G ethernet, but some modules use 1200.
I guess start at the correct value and then adjust to allow a range
as we see more modules.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!