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:   Mon, 23 Dec 2019 12:07:31 +0000
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Madalin Bucur <madalin.bucur@....com>
Cc:     "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>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH 1/6] net: phy: add interface modes for XFI, SFI

On Thu, Dec 19, 2019 at 06:32:51PM +0000, Madalin Bucur wrote:
> 10GBase-R could be used as a common nominator but just as well 10G and
> remove the rest while we're at it. There are/may be differences in
> features, differences in the way the HW is configured (the most
> important aspect) and one should be able to determine what interface
> type is in use to properly configure the HW. SFI does not have the CDR
> function in the PMD, relying on the PMA signal conditioning vs the XFI
> that requires this in the PMD.

I've now found a copy of INF-8077i on the net, which seems to be the
document that defines XFI. The definition in there seems to be very
similar to SFI in that it is an electrical specification, not a
protocol specification, and, just like SFI, it defines the electrical
characteristics at the cage, not at the serdes. Therefore, the effects
of the board layout come into play to achieve compliance with XFI.

Just like SFI, XFI can be used with multiple different underlying
protocols. I quote:

  "The XFI interface is designed to support SONET OC-192,
  IEEE.Std-802.3ae, 10GFC and G.709(OTU-2) applications."

Therefore, to describe 10GBASE-R as "XFI" is most definitely incorrect.
10GBASE-R is just _one_ protocol that can be run over XFI, but it is
not the only one.

As for CDR, INF-8077i says:

  "The XFP module shall include a Signal Conditioner based on CDR (Clock
  Data Recovery) technology for complete regeneration."

Whereas for SFP modules, SFF-8472 revision 11.4 added optional support
for CDR on the modules.

In any case, the CDR is a matter for the module itself, not for the
host, so it seems that isn't relevent.

Everything that I've said concerning SFI in my previous email (in date
order), and why we should not be defining that as a phy_interface_t
seems to also apply to XFI from what I've read in INF-8077i, and it
seems my original decision that we should not separately define
XFI and SFI from 10GBASE-R is well founded.

Given that meeting these electrical characteristics involves the
effects of the board, and it is impractical for a board to switch
between different electrical characteristics at runtime (routing serdes
lanes to both a SFP+ and XFP cage is impractical due to reflections on
unterminated paths) I really don't see any reason why we need two
different phy_interface_t definitions for these.  As mentioned, the
difference between XFI and SFI is electrical, and involves the board
layout, which is a platform specific issue.

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