On Mon, Oct 12, 2020 at 02:42:54PM -0700, Richard Cochran wrote: > If you want, you can run your PHC using the linuxptp "free_running" > option. Then, you can use the TIME_STATUS_NP management request to > use the remote time signal in your application. I was expecting some sort of reaction to this from Kamil or Kurt. I don't think that 'using the remote time signal in an application' is all that needs to be done with the gPTP time, at least for a switch with the hardware features that hellcreek has. Ultimately it should be fed back into the hardware, such that the scheduler based on 802.1Q clause 8.6.8.4 "Enhancements for scheduled traffic" has some time scale based on which it can run. Running tc-taprio offload on top of an unsynchronized clock is not something productive. So the discussion is about how to have the cake and eat it at the same time. Silicon vendors eager to follow the latest trends in standards are implementing hybrid PTP clocks, where an unsynchronizable version of the clock delivers MAC timestamps to the application stack, and a synchronizable wrapper over that same clock is what gets fed into the offloading engines, like the ones behind the tc-taprio and tc-gate offload. Some of these vendors perform cross-timestamping (they deliver a timestamp from the MAC with 2, or 3, or 4, timestamps, depending on how many PHCs that MAC has wired to it), some don't, and just deliver a single timestamp from a configurable source. The operating system is supposed to ??? in order to synchronize the synchronizable clock to the virtual time retrieved via TIME_STATUS_NP that you're talking about. The question is what to replace that ??? with, of course. > > I'm not an expert in kernel implementation but we have plans to discuss > > possible approaches in the near future. > > I don't see any need for kernel changes in this area. I'm not an expert in kernel implementation either, but perhaps in the light of this, you can revisit the idea that kernel changes will not be needed (or explain more, if you still think they aren't). Since IEEE 60802 keeps talking about multiple time domains to be used with 802.1AS-rev (a 'universal clock domain' and a 'working clock domain'), a decision needs to be taken somewhere about which time base you're going to use as a source for synchronizing your tc-taprio clock. That decision should best be taken at the application level, so in my opinion this is an argument that the application should have explicit access to the unsynchronizable and to the synchronizable versions of the PTP clock. In the Linux kernel API, a network interface can have at most one PHC. -------------- DISCLAIMER Yes, I know full well that everyone can write a standard, but not everyone can implement one. At the end of the day, I'm not trying to make an argument whether the end result is worth making all these changes. I'm only here to learn what other people are doing, how, and most importantly, why.
