Re: [PATCH net-next] ptp: add vclock timestamp conversion IOCTL

[Richard Cochran <richardcochran@gmail.com>]

On Wed, Sep 29, 2021 at 05:00:56PM +0200, Sebastien Laveze wrote:
> On Tue, 2021-09-28 at 06:31 -0700, Richard Cochran wrote:
> > On Tue, Sep 28, 2021 at 01:50:23PM +0200, Sebastien Laveze wrote:
> > > Yes that would do it. Only drawback is that ALL rx and tx timestamps
> > > are converted to the N domains instead of a few as needed.
> > 
> > No, the kernel would provide only those that are selected by the
> > program via the socket option API.
> 
> But _all_ timestamps (rx and tx) are converted when a domain is
> selected.

So what?  It is only a mult/shift.  Cheaper than syscall by far.

> If we consider gPTP,
> -using the ioctl, you only need to convert the sync receive timestamps.
> PDelay (rx, tx, fup), sync (tx and fup) and signalling don't need to be
> converted. So that's for a default sync period of 125 ms, 8 ioctl /
> second / domain.

Well, today that is true, for your very specific use case.  But we
don't invent kernel interfaces for one-off projects.

> -doing the conversion in the kernel will necessarly be done for every
> timestamp handled by the socket. In addition, the vclock device lookup
> is not free as well and done for _each_ conversion.

Sounds like something that can be optimized in the kernel implementation.

> From a high-level view, I understand that you would have N
> instance/process of linuxptp to support N domains ?

Yes.

> CMLDS performed by
> one of them and then some signalling to the other instances ?

Yes, something like that.  One process measures peer delay, and the
others read the result via management messages (could also be pushed
via ptp4l's management notification method).
 
> What we miss currently in the kernel for a better multi-domain usage
> and would like to find a solution:
> -allow PHC adjustment with virtual clocks. Otherwise scheduled traffic
> cannot be used... (I've read your comments on this topic, we are
> experimenting things on MCUs and we need to assess on measurements)

Yeah, so you cannot have it both ways, I'm afraid.  Either you adjust
the HW clock or not.  If you don't, it becomes impractical to program
the event registers for output signals.  (Time stamps on input signals
are not an issue, though)

> -timer support for virtual clocks (nanosleep likely, as yous suggested
> IIRC).

Right, and this is (probably) difficult to sell on lkml.  Look at the
hrtimer implementation to see what I mean.

I could imagine adding one additional hrtimer base under user space
control that isn't clock_monotonic or _realtime or _tai, but not N new
bases.

I think the best option for user space wanting timers in multiple
domains is to periodically do 

   gettime(monotonic); gettime(vclock); gettime(monotonic);

figure the conversion, and schedule using clock_monotonic.


HTH,
Richard