netdev - RE: [PATCH net-next v3 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]

Date:   Thu, 2 Feb 2017 16:36:05 +0000
From:   "Mintz, Yuval" <Yuval.Mintz@...ium.com>
To:     Richard Cochran <richardcochran@...il.com>,
        "Kalluru, Sudarsana" <Sudarsana.Kalluru@...ium.com>
CC:     "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>
Subject: RE: [PATCH net-next v3 1/2] qed: Add infrastructure for PTP support.

> > +		for (val = 0; val <= 7; val++) {
> > +			period1 = div_s64(val * 1000000000, ppb);
> > +			period1 -= 8;
> > +			period1 >>= 4;
> > +			if (period1 < 1)
> > +				period1 = 1;
> > +			if (period1 > 0xFFFFFFE)
> > +				period1 = 0xFFFFFFE;
> > +			period2 = period1 + 1;
> > +
> > +			temp = div_s64(val * 1000000000, (period1 * 16 + 8));
> > +			dif1 = ppb - temp;
> > +			if (dif1 < 0)
> > +				dif1 = -dif1;
> > +
> > +			temp = div_s64(val * 1000000000, (period2 * 16 + 8));
> 
> Forgetting the useless val=0 case, this still takes 21 64-bit divisions on every
> adjustment.  There must be a better way.
> 
> @tglx - Do you have a hint for Sudarsana?

Maybe we can improve it a bit by making it even uglier
and save one of the divisions here; But that would still leave a 2-digit
number of divisions. I don't have an alternative algorithm that would
solve that.

I have to say I still don't see the importance of this -
I thought we've previously agree that the 'reasonable' scenario
wouldn't use this more than 16 times a second, so it's clearly
not datapath.
Optimizing stuff is great, but optimizing less critical paths
is partially wasted effort. As such - I don't think this should
be a 'blocking' criteria for the submission.

Having written all of that, If someone raises to the challenge
and can efficiently improve the logic, we'd obviously
be delighted to take whatever solution is given.

Thanks,
Yuval