netdev - Re: [PATCH v3 5/8] net: dsa: hellcreek: Add TAPRIO offloading 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] [day] [month] [year] [list]

Date:   Tue, 1 Sep 2020 17:47:55 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Kurt Kanzenbach <kurt@...utronix.de>
Cc:     Vinicius Costa Gomes <vinicius.gomes@...el.com>,
        Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Richard Cochran <richardcochran@...il.com>,
        Kamil Alkhouri <kamil.alkhouri@...offenburg.de>,
        ilias.apalodimas@...aro.org
Subject: Re: [PATCH v3 5/8] net: dsa: hellcreek: Add TAPRIO offloading support

On Tue, Sep 01, 2020 at 04:20:00PM +0200, Kurt Kanzenbach wrote:
>
> After giving this a bit more thought, it can be implemented by using
> workqueues only. That ptp time is "cached" anyway the we could just
> periodically check for the base time arrival. That should solve the
> irqsave and the being synchronized problem.
>
> Thanks,
> Kurt

Ok, this sounds simple enough. If the base-time is within 8 seconds of
the current PTP time, then apply the taprio configuration, otherwise
reschedule a delayed workqueue after N seconds (where N has what
value?).

If my math is correct, then N can't simply be the the delta between the
current PTP time and the (base-time minus 8 seconds) value - i.e. just
one schedule_delayed_work - because at large deltas, the PHC frequency
adjustment (+/- 6.25%) starts to matter. At maximum frequency, the PHC
can exceed the monotonic clock of the system by more than 8 seconds in
(8 * 100 / 6.25) = 128 seconds. So if the base-time is in the future by
more than 128 seconds and you plan for a single schedule_delayed_work,
there's a chance that you'll miss the window. And even if you try to
compensate using the current frequency adjustment, that's all that it is
- the current, instantaneous frequency adjustment, not the one from 128
seconds later.

How about N being half that delta? It's not ideal, since there would
need to be log2(delta) reschedules, but at least the error of the first
approximation won't propagate to the next, and the delta will keep
decreasing as time passes, therefore so will the error.

Thanks,
-Vladimir