netdev - Re: [RFC PATCH net-next 0/6] ptp: Support hardware clocks with additional free running time

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:   Sun, 6 Mar 2022 19:38:55 +0100
From:   Gerhard Engleder <gerhard@...leder-embedded.com>
To:     Richard Cochran <richardcochran@...il.com>
Cc:     yangbo.lu@....com, David Miller <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, mlichvar@...hat.com,
        Vinicius Costa Gomes <vinicius.gomes@...el.com>,
        netdev <netdev@...r.kernel.org>
Subject: Re: [RFC PATCH net-next 0/6] ptp: Support hardware clocks with
 additional free running time

On Sun, Mar 6, 2022 at 6:05 PM Richard Cochran <richardcochran@...il.com> wrote:
> > ptp vclocks require a clock with free running time for the timecounter.
> > Currently only a physical clock forced to free running is supported.
> > If vclocks are used, then the physical clock cannot be synchronized
> > anymore. The synchronized time is not available in hardware in this
> > case. As a result, timed transmission with ETF/TAPRIO hardware support
> > is not possible anymore.
>
> NAK.
>
> I don't see why you don't simply provide two PHC instances from this
> one device.

Because with vclocks the user space interface is already available. Also In
my opinion it is a good fit. The second PHC would be based on the free running
hardware counter. So it would not provide any additional functionality compared
to the vclocks based on it.

Are two PHC instances supported? At least for ethtool there is only a single
phc_index field.

> AFAICT, this series is not needed at all, as the existing API covers
> this use case already.

I assume that you mean for ETF the transmission time can be converted,
similar like for time stamps. So for ETF you are right. It was too quick to
mention ETF along with TAPRIO.

My use case is TAPRIO with hardware support. For TAPRIO the hardware
has to act based on the synchronized time within the TSN network. No
transmission times, which could be converted, are used. The hardware
is in charge to transmit frames from a certain queue only during defined
intervals. These intervals are based on the synchronized time. So the
hardware must be synchronized somehow. This is my solution to keep
the hardware synchronized while vclocks are in use.

How can I cover my use case with the existing API? I had no idea so far.

Thanks!

Gerhard