netdev - RE: [PATCH net-next 6/6] docs: net: Add description of SyncE interfaces

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, 5 Nov 2021 11:51:48 +0000
From:   "Machnikowski, Maciej" <maciej.machnikowski@...el.com>
To:     Jakub Kicinski <kuba@...nel.org>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>,
        "richardcochran@...il.com" <richardcochran@...il.com>,
        "abyagowi@...com" <abyagowi@...com>,
        "Nguyen, Anthony L" <anthony.l.nguyen@...el.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
        "idosch@...sch.org" <idosch@...sch.org>,
        "mkubecek@...e.cz" <mkubecek@...e.cz>,
        "saeed@...nel.org" <saeed@...nel.org>,
        "michael.chan@...adcom.com" <michael.chan@...adcom.com>
Subject: RE: [PATCH net-next 6/6] docs: net: Add description of SyncE
 interfaces

> -----Original Message-----
> From: Jakub Kicinski <kuba@...nel.org>
> Sent: Thursday, November 4, 2021 7:09 PM
> To: Machnikowski, Maciej <maciej.machnikowski@...el.com>
> Subject: Re: [PATCH net-next 6/6] docs: net: Add description of SyncE
> interfaces
> 
> On Thu,  4 Nov 2021 09:12:31 +0100 Maciej Machnikowski wrote:
> > +Synchronous Ethernet networks use a physical layer clock to syntonize
> > +the frequency across different network elements.
> > +
> > +Basic SyncE node defined in the ITU-T G.8264 consist of an Ethernet
> > +Equipment Clock (EEC) and can recover synchronization
> > +from the synchronization inputs - either traffic interfaces or external
> > +frequency sources.
> > +The EEC can synchronize its frequency (syntonize) to any of those
> sources.
> > +It is also able to select a synchronization source through priority tables
> > +and synchronization status messaging. It also provides necessary
> > +filtering and holdover capabilities.
> > +
> > +The following interface can be applicable to diffferent packet network
> types
> > +following ITU-T G.8261/G.8262 recommendations.
> 
> Can we get a diagram in here in terms of how the port feeds its
> recovered Rx freq into EEC and that feeds freq of Tx on other ports?

Will try - yet my ASCII art skills are not very well developed :)

> I'm still struggling to understand your reasoning around not making
> EEC its own object. "We can do this later" seems like trading
> relatively little effort now for extra work for driver and application
> developers for ever.

That's not the case. We need EEC and the other subsystem we wanted
to make is the DPLL subsystem. While EEC can be a DPLL - it doesn't have
to, and it's also the other way round - the DPLL can have numerous different
usages.
When we add the DPLL subsystem support the future work will be as simple 
as routing the EEC state read function to the DPLL subsystem. But if someone
decides to use a different HW implementation he will still be able to
implement his own version of API to handle it without a bigger DPLL block

> Also patch 3 still has a kdoc warning.
Will fix.