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] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 25 Aug 2020 12:38:30 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Kurt Kanzenbach <kurt@...utronix.de>
Cc:     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, Aug 25, 2020 at 11:33:53AM +0200, Kurt Kanzenbach wrote:
> On Tue Aug 25 2020, Vladimir Oltean wrote:
> > On Thu, Aug 20, 2020 at 10:11:15AM +0200, Kurt Kanzenbach wrote:
> >
> > Explain again how this works, please? The hrtimer measures the CLOCK_TAI
> > of the CPU, but you are offloading the CLOCK_TAI domain of the NIC? So
> > you are assuming that the CPU and the NIC PHC are synchronized? What if
> > they aren't?
> 
> Yes, I assume that's synchronized with e.g. phc2sys.
> 

My intuition tells me that this isn't the user's expectation, and that
it should do the right thing even if it's not synchronized to the system
clock.

> >
> > And what if the base-time is in the past, do you deal with that (how
> > does the hardware deal with a base-time in the past)?
> > A base-time in the past (example: 0) should work: you should advance the
> > base-time into the nearest future multiple of the cycle-time, to at
> > least preserve phase correctness of the schedule.
> 
> If the hrtimer is programmed with a value in the past, it fires
> instantly.

Yes, it does.

> The callback is executed and the start time is programmed.
> 

With a valid value from the hardware's perspective?

Thanks,
-Vladimir