netdev - RE: [Intel-wired-lan] [RFC net-next 1/7] ptp: Add interface for acquiring DPLL state

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:   Wed, 18 Aug 2021 18:14:13 +0000
From:   "Keller, Jacob E" <jacob.e.keller@...el.com>
To:     Richard Cochran <richardcochran@...il.com>,
        "Machnikowski, Maciej" <maciej.machnikowski@...el.com>
CC:     "cong.wang@...edance.com" <cong.wang@...edance.com>,
        "arnd@...db.de" <arnd@...db.de>,
        "gustavoars@...nel.org" <gustavoars@...nel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "colin.king@...onical.com" <colin.king@...onical.com>,
        "intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>,
        "nikolay@...dia.com" <nikolay@...dia.com>,
        "linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "shuah@...nel.org" <shuah@...nel.org>,
        "davem@...emloft.net" <davem@...emloft.net>
Subject: RE: [Intel-wired-lan] [RFC net-next 1/7] ptp: Add interface for
 acquiring DPLL state



> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@...osl.org> On Behalf Of
> Richard Cochran
> Sent: Wednesday, August 18, 2021 10:03 AM
> To: Machnikowski, Maciej <maciej.machnikowski@...el.com>
> Cc: cong.wang@...edance.com; arnd@...db.de; gustavoars@...nel.org;
> netdev@...r.kernel.org; linux-kernel@...r.kernel.org;
> colin.king@...onical.com; intel-wired-lan@...ts.osuosl.org; nikolay@...dia.com;
> linux-kselftest@...r.kernel.org; kuba@...nel.org; shuah@...nel.org;
> davem@...emloft.net
> Subject: Re: [Intel-wired-lan] [RFC net-next 1/7] ptp: Add interface for acquiring
> DPLL state
> 
> On Tue, Aug 17, 2021 at 09:41:49AM +0000, Machnikowski, Maciej wrote:
> 
> > The logic behind adding the DPLL state to the PTP subsystem is that SyncE DPLL
> on Network adapters, in most cases, drive the PTP timer.
> 
> So what?  The logic in the HW has nothing to do with the proper user
> space interfaces.  For example, we have SO_TIMESTAMPING and PHC as
> separate APIs, even though HW devices often implement both.
> 
> > Having access to it in the PTP subsystem is beneficial, as Telco
> > standards, like G.8275.1/2, require a different behavior depending
> > on the SyncE availability and state.
> 
> Right, but this does say anything about the API.
> 
> > Multiport adapters use a single PLL to drive all ports. If we add
> > the PLL interface to the PTP device - a tool that would implement
> > support for Telco standards would have a single source of
> > information about the presence and state of physical sync.
> 
> Not really.  Nothing guarantees a sane mapping from MAC to PHC.  In
> many systems, there a many of each.
> 

Well, I think the point of placing it in the PTP subsystem is that there is a sane mapping between PHC <-> DPLL. There's only one DPLL for the PHC.

Thanks,
Jake