netdev - RE: [PATCH net-next v2 2/2] qede: Add driver support for PTP.

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, 31 Jan 2017 15:08:11 +0000
From:   "Mintz, Yuval" <Yuval.Mintz@...ium.com>
To:     Richard Cochran <richardcochran@...il.com>
CC:     David Laight <David.Laight@...LAB.COM>,
        "Kalluru, Sudarsana" <Sudarsana.Kalluru@...ium.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [PATCH net-next v2 2/2] qede: Add driver support for PTP.

> > I feel like I'm missing something. Again.
> > I thought the reasonable rate of rate-adjustment is once a second,
> > which doesn't make it 'hot' in any way.
> > In which scenario would we frequently encounter this configuration?
> 
> The Sync message rate is not 1 per second, but rather the interval is
> specified by the PTP profile as 2^N seconds, -128 <= N < 128.
> 
> This is called the logSyncInterval, and in the Telecom profile [1] for
> example, N = -4.

While it surely answers my question, I still don't think of an event
reoccurring 16 times a second as optimization-crucial.
Is there any reasonable scenario where the interval is
significantly smaller, or is it merely some theoretical specification?
[I'd like to see the machine that can handle the 2^(-128) sec interval]

> Anyhow, as far the original question goes, maybe you could have the
> specific HW driver pass its adjfreq function pointer into the generic
> driver and let the generic driver copy it directly into the
> ptp_clock_info.

Again, I don't see how we can achieve that given that qede has to check
Its internal state to check whether it's right to utilize the ptp-related hw
configurations and only then call the qed function. As qed can't do it for
qede, we can't directly map qed's function into the ptp_clock_info,
but rather have to call it after taking qede's state-lock.