netdev - Re: [PATCH RFC net-next 00/13] Phylink PCS updates

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:   Tue, 14 Jul 2020 14:18:32 +0100
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Ioana Ciornei <ioana.ciornei@....com>,
        Alexandru Marginean <alexandru.marginean@....com>,
        Claudiu Manoil <claudiu.manoil@....com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        "michael@...le.cc" <michael@...le.cc>, netdev@...r.kernel.org,
        Vladimir Oltean <vladimir.oltean@....com>
Subject: Re: [PATCH RFC net-next 00/13] Phylink PCS updates

On Tue, Jul 14, 2020 at 11:49:58AM +0300, Vladimir Oltean wrote:
> Are you going to post a non-RFC version?

I'm waiting for the remaining patches to be reviewed; Florian reviewed
the first six patches (which are not the important ones in the series)
and that seems to be where things have stopped. There has been no
change, so I don't see there's much point to reposting the series.

I'd actually given up pushing this further; I've seen patches go by that
purpetuate the idea that the PCS is handled by phylib.  I feel like I'm
wasting my time with this.

> I think this series makes a lot of sense overall and is a good
> consolidation for the type of interfaces that are already established in
> Linux.
> 
> This changes the landscape of how Linux is dealing with a MAC-side
> clause 37 PCS, and should constitute a workable base even for clause 49
> PCSs when those use a clause 37 auto-negotiation system (like USXGMII
> and its various multi-port variants).

Yes.

> Where I have some doubts is a
> clause 49 PCS which uses a clause 73 auto-negotiation system, I would
> like to understand your vision of how deep phylink is going to go into
> the PMD layer, especially where it is not obvious that said layer is
> integrated with the MAC.

I have only considered up to 10GBASE-R based systems as that is the
limit of what I can practically test here.  I have one system that
offers a QSFP+ cage, and I have a QSFP+ to 4x SFP+ (10G) splitter
cable - so that's basically 4x 10GBASE-CR rather than 40GBASE-CR.

I am anticipating that clause 73 will be handled in a very similar way
to clause 37.  The clause 73 "technology ability" field defines the
capabilities of the link, but as we are finding with 10GBASE-R based
setups with copper PHYs, the capabilities of the link may not be what
we want to report to the user, especially if the copper PHY is capable
of rate adaption.  Hence, it may be possible to have a backplane link
that connects to a copper PHY that does rate adaption:

MAC <--> Clause 73 PCS <--backplane--> PHY <--base-T--> remote system

This is entirely possible from what I've seen in one NBASE-T PHY
datasheet.  The PHY is documented as being capable of negotiating a
10GBASE-KR link with the host system, while offering 10GBASE-R,
1000BASE-X, 10GBASE-T, 5GBASE-T, 2.5GBASE-T, 1GBASE-T, 100BASE-T, and
10BASE-T on the media side.  The follow-on question is whether that
PHY is likely to be accessible to the system on the other end of the
backplane link somehow - either through some kind of firmware link
or direct access.  That is not possible to know without having
experience with such systems.

That said, with the splitting of the PCS from the MAC in phylink, there
is the possibility for the PCS to be implemented as an entirely
separate driver to the MAC driver, although there needs to be some
infrastructure to make that work sanely.  Right now, it is the MAC
responsibility to attach the PCS to phylink, which is the right way
to handle it for setups where the PCS is closely tied to the MAC, such
as Marvell NETA and PP2 where the PCS is indistinguishable from the
MAC, and will likely remain so for such setups.  However, if we need
to also support entirely separate PCS, I don't see any big issues
with that now that we have this split.

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