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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 31 Jan 2017 18:43:27 +0100
From:   Richard Cochran <richardcochran@...il.com>
To:     "Mintz, Yuval" <Yuval.Mintz@...ium.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.

On Tue, Jan 31, 2017 at 03:08:11PM +0000, Mintz, Yuval wrote:
> 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?

Its theoretical, like ipv6 addresses.

> [I'd like to see the machine that can handle the 2^(-128) sec interval]

;)
 
> 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.

Fair enough.

Thanks,
Richard