On Wed, Nov 25, 2020 at 10:34:44AM -0800, Richard Cochran wrote:
> On Wed, Nov 25, 2020 at 08:36:59AM +0100, Volodymyr Bendiuga wrote:
> > Hence, our major concern still remains: is there something we have missed?
> > Can TC operate in 1-step mode out-of-the-box? Is there anyone out there
> > running 1-step TC?
>
> linuxptp implements 2-step TC only.
>
> In general, 1-step TC is not possible because of the way that the
> available hardware works.
So there would be two types of one-step TC that I see:
1. devices that just support one-step timestamping (i.e. 2 or more NICs
that share a common PHC - for example dpaa2 from my previous email).
I don't necessarily see a huge problem for these. Just like we support
one-step peer delay for these, we might attempt to update the
residence time for Sync too.
2. devices with one-step TC in hardware (switches). These would need to
skip tc_fwd_sync() altogether, since they are capable of forwarding
the Sync message autonomously between their front-panel ports.
It is an open question what should ptp4l attempt to do with these.
Some complications that I can think of:
- a switch that has 2 interfaces under a bridge will forward Sync
messages autonomously, whereas a switch that has the interfaces
unbridged won't do that. Does ptp4l need to be aware of that bridge?
- if we allow the switch to forward the one-step Sync messages
autonomously, then we need a kernel interface to pass the peer
delay calculated by ptp4l, for each port, back into the hardware,
so that the switch can use that for the correctionField updates.
- the Sync messages might still be forwarded to the CPU for various
purposes, but in general, if bridged, we must assume that ptp4l sees
merely a copy of that Sync message, and not the only one. So we
might use these Sync messages for syntonization, but definitely not
forward them. And it should definitely not generate Sync messages
of its own, on PS_MASTER ports.
- alternatively, we might require the driver to add an ACL for PTP
traffic, and then it all boils down to type 1 of devices. However,
this might not always be supported, so we might just be kicking the
can down the road.
The spectrum of options is indeed large. Is there something in
particular that you would prefer to see?
_______________________________________________
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
