netdev - Re: [PATCH 1/6] net: phy: add interface modes for XFI, SFI

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] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 3 Jan 2020 09:42:04 +0000
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     "Madalin Bucur (OSS)" <madalin.bucur@....nxp.com>
Cc:     "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "andrew@...n.ch" <andrew@...n.ch>,
        "f.fainelli@...il.com" <f.fainelli@...il.com>,
        "hkallweit1@...il.com" <hkallweit1@...il.com>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>
Subject: Re: [PATCH 1/6] net: phy: add interface modes for XFI, SFI

On Fri, Jan 03, 2020 at 09:27:18AM +0000, Russell King - ARM Linux admin wrote:
> Merely specifying "xfi" does not tell you what you need to do to achieve
> XFI compliance at the point defined in INF8077i.  Plus, XFI can also be
> protocols _other_ than 10GBASE-R.
> 
> Claiming that "XFI" properly defines the interface is utter rubbish. It
> does not. XFI defines the electrical characteristics *only* and not
> the underlying protocol. It is not limited to 10GBASE-R, but includes
> other protocols as well.

Let me quote from INF-8077i, which is the XFP MSA, the document
responsible for defining XFI:

3.1 INTRODUCTION
   XFI signaling is based on high speed low voltage logic, with nominal 100
   Ohms differential impedance and AC coupled in the module. XFI was de-
   veloped with the primary goal of low power and low Electro-Magnetic-In-

   terference (EMI). To satisfy this requirement the nominal differential signal   levels are 500 mV p-p with edge speed control to reduce EMI.

3.2 XFI APPLICATIONS DEFINITION
   The application reference model for XFI, which connects a high speed
   ASIC/SERDES to the XFP module is shown in Figure 4. The XFI interface
   is designed to support SONET OC-192, IEEE.Std-802.3ae, 10GFC and
   G.709(OTU-2) applications. The SERDES is required to meet the applica-
   tion requirements for jitter generation and transfer when interfaced with a
   compliant XFP module through an XFP compliant channel. Modules or

   hosts designed only for 10 Gigabit Ethernet or 10GFC are not required to
   meet more stringent Telecom jitter requirements. XFI supported data
   rates are listed in Table 5. XFP compliant module are not required to sup-
   port all the rates listed in Table 5 in simultaneously.

   Standard                            Description           Nominal Bit Rate     Units
   OC-192/SDH-64                         SONET                     9.95         Gigabaud
   IEEE std-802.3ae             10 Gb/s Ethernet LAN PHY           10.31        Gigabaud
   INCITS/T11 Project 1413-D             10GFC                     10.52        Gigabaud
   ITU G.709(OTU-2)                 OC-192 Over FEC                10.70        Gigabaud
   Emerging                     10Gb/s Ethernet Over G.709         11.09        Gigabaud

So here, we can clearly see that it's possible to run SONET, 10GBASE-R,
10G Fiberchannel, OC-192, and G.709 over XFI, so XFI does not describe
_just_ ethernet. If we're going to be configuring a serdes to output
XFI, we need to know a lot more than just "XFI".

   XFI Compliance points are defined as the following:

   •   A: SerDes transmitter output at ASIC/SerDes package pin on a DUT
       board 3.6 and A.1
   •   B: Host system SerDes output across the host board and connector
       at the Host Compliance Test Card 3.7.1 and A.2
   •   B': XFP transmitter input across the Module Compliance Test Board
       3.8.1 and A.3.
   •   C: Host system input at the Host Compliance Test Card input 3.7.2
       and A.2
   •   C': XFP module output across the Module Compliance Test Board
       3.8.2 and A.3.

   •   D: ASIC/SerDes input package pin on the DUT board 3.6.2 and A.1.

   ASIC/SerDes compliance points are informative.

So the electrical points that count are B, B', C and C'. A and D
are merely "informative".  Hence, compliance with XFI is required
to take the entire platform into account, not just the output of
the serdes/asic.  That means the performance of the PCB needs to
be described in DT if you want to achieve compliance with XFI.
phy_interface_t can't do that.

So, let me re-iterate: neither XFI nor SFI are suitable for
phy_interface_t. XFI defines merely a group of possible protocols
and an electrical specification. It doesn't tell you which of those
protocols you should be using.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up