Re: [PATCH net-next v6 4/7] net: dsa: hellcreek: Add support for hardware timestamping

[Vladimir Oltean <olteanv@gmail.com>]

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.