netdev - RE: [PATCH net-next v4 1/2] qed: Add infrastructure for PTP support.

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]

Message-ID: <BL2PR07MB2306751ABE3FC347E40302B18D460@BL2PR07MB2306.namprd07.prod.outlook.com>
Date:   Sun, 12 Feb 2017 15:07:34 +0000
From:   "Mintz, Yuval" <Yuval.Mintz@...ium.com>
To:     Richard Cochran <richardcochran@...il.com>,
        "davem@...emloft.net" <davem@...emloft.net>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "Kalluru, Sudarsana" <Sudarsana.Kalluru@...ium.com>
Subject: RE: [PATCH net-next v4 1/2] qed: Add infrastructure for PTP support.

> > Your suggestion seems to:
> >   a. Assume that the required period should be in ns, not in
> >       16*ns units.
> >   b. mishandles the +8/-8 in the calculation.
> >   c. Doesn't seem to consider the upper bound on period.
> 
> Duh, you would have to convert the result into the proper form for the HW
> register and add bounds checking.  I mean, that goes without saying.
> The important fact is that your algorithm it not optimal for ppm < 60.

Your algorithm ignores the HW limitation. Consider (ppb == 1): 
your logic would output N == 7, *M == 7000000000,
   Which has perfect accuracy [N / *M is 1 / 10^9].
But the solution for
   'period' * 16 + 8 == 7 * 10^9
isn't a whole number, so this result doesn't really reflect the actual
approximation error since we couldn't configure it to HW.

The original would return val == 1, period == 62499999; While this
does have some error [val / (period * 16 + 8) is slightly bigger
than 1 / 10^9, error at 18[?] digit after dot], it's the best we can
configure for the HW.

One simple adjustment we could do is simply break from the loop
If 'diff == 0'. At least for small PPB value this would be hit relatively quickly.

> > One thing I still don't get is *why* we're trying to optimize this
> > area of the code -
> 
> So you prefer using 21 64-bit divisions when using 8 produces better results?

No. In an ideal world, I would have liked optimizing everything.
But in this world if I do find time to spend on optimizations 
I rather do that for the stuff that matters. I.e., datapath.