netdev - Re: [net-next 0/6] ptp: support virtual clocks for multiple domains

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, 11 May 2021 08:49:48 -0700
From:   Richard Cochran <richardcochran@...il.com>
To:     "Y.b. Lu" <yangbo.lu@....com>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "David S . Miller" <davem@...emloft.net>,
        Claudiu Manoil <claudiu.manoil@....com>,
        Jakub Kicinski <kuba@...nel.org>
Subject: Re: [net-next 0/6] ptp: support virtual clocks for multiple domains

On Tue, May 11, 2021 at 10:40:15AM +0000, Y.b. Lu wrote:
> What I thought was in code writing registers to adjust physical clock frequency, and immediately adjusting virtual clocks in opposite direction.
> Make the operations atomic by locking. Assume the code execution has a DELAY, and the frequency adjusted is PPM.
> Then the time error affecting on virtual clock will be DELAY * PPM. I'm not sure what the DELAY value will be on other platforms.
> Just for example, for 1us delay, 1000ppm adjustment will have 1ns time error.
> 
> But indeed, this approach may be not feasible as you said. Especially it is adjusting clock in max frequency, and there are many virtual clocks.
> The time error may be large enough to cause issues. (I'm not sure whether I understand you correctly, sorry.)

You understand correctly.

> So, a question is, for hardware which supports only one PTP clock, can multiple domains be supported where physical clock also participates in synchronization of a domain?
> (Because sometime the physical clock is required to be synchronized for TSN using, or other usages.)
> Do you think it's possible?

No, it won't work.  You can't adjust both the physical clock and the
timecounters at the same time.  The code would be an awful hack, and
it would not work in all real world circumstances.  If the kernel
offers a new time service, then it has to work always.

So, getting back to my user space idea, it _would_ work to let the
application stack control the HW clock as before, but to track the
other domains numerically.  Then, the other applications could use the
TIME_STATUS_NP management message (designed for use with gPTP and
free_running) to get the current time in the other domains.

So take your pick.  You can't have it both ways, I'm afraid.

> > In addition to that, you will need a way to make the relationships between the
> > clocks and the network interfaces discoverable.
> 
> Agree. This should be done carefully and everything should be considered.
> Will converting physical clock ptp0 to virtual clock ptp0 introduce more effort to implement,
> comparing to keep physical clock ptp0 but limit to use it?

I think either way, it would be a substantial change in the kernel
code.

> > It needs more thought and careful design, but I think having
> > clock_gettime() available for the different clocks would be nice to have for the
> > applications.
> 
> Thank you. Then regarding the domain timestamp, do you think it's proper to do the conversion in kernel as I implemented.

Yes, it would be very nice for the applications, because they wouldn't
have to use a different API for gettime().

The drawback is that you loose the ability to generate synchronized
signals in HW from the physical clock.

(Time stamping inputs would still work, because the timecounter code
cleverly allows that.)

Thanks,
Richard