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 11:55:37 +0200
From:   Kurt Kanzenbach <kurt@...utronix.de>
To:     Vladimir Oltean <olteanv@...il.com>
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, Vladimir Oltean wrote:
> 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.

I get your point. But how to do it? We would need a timer based on the
PTP clock in the switch.

>
>> >
>> > 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?

Yes. That's no problem.

Thanks,
Kurt

Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ