Hi Vladimir,
> How? The egress port has no idea what t1 was. Where is t1 recorded?
The hardware we use, Marvell Alaska 88e1548P phy, has a couple of possible
solutions to our given problem, that is to say, updating the residence time
(t2(egress) - t1(ingress)). The one we have chosen, does the following if
configured for TC mode:
1. SYNC packet arrives to HW on port 1, t1 is recorded, and, placed
into reserved area of the packet
2. SYNC packet travels up towards linuxptp
3.a If we run in P2P mode, uplink delay is added to packet’s correction
field, and the packet is forwarded.
3.b If we run in E2E mode, the packet is simply forwarded.
4. HW receives SYNC packet on port 2, t1 is read from packets reserved
area, t2 is taken, residence time is calculated (t2 - t1) and added to
correction field. Packet is sent.
Since it is common sense that the standard describes the behaviour and not
implementation, the HW we use, implements in its own peculiar way, the solution
to our problem. Different hardware may have contrasting solution, implemented
in its own mysterious way, but as long as the result is up to what the standard
has imposed, the same generic solution in linuxptp would work.
Generic solution will not work for hardware X, if hardware X is unable to
calculate residence time in 1-step; but let’s remember that 1-step residence
time calculation is a requirement enforced by the standard. Any deviation in HW
from the standard - is a complication in SW.
Generic solution is absolutely not needed for hardware-oriented TCs, capable of
forwarding packets on their own, and that is obvious. Based on your description
Vladimir, sja1105 is a great example of such hardware, capable of acting in
1-step E2E TC mode. This type of HW falls out of the scope of the proposed
patch, since it does not require software assistance in that regard.
Here we see 2 big categories of TCs:
1. Hardware-oriented
2. Software-assisted
From this we may draw a simple conclusion, namely, that only software-assisted
TC’s are qualified for this patch, since they rely on linuxptp in general.
We may further split software-assisted TCs into 2 general sub-categories:
1. TCs that fully comply with 1-step directives of IEEE 1588 V2 standard
2. TCs that only partially comply with 1-step directives of IEEE 1588
V2 standard
If we start with the second sub-category, we see a plethora of different HW,
each of which, or at least majority, deserve support in linuxptp. They do not
have this support yet, and to get it they would need to patch linuxptp, asking
for assistance. Some hardware families would need a few patches, specific to
their platform. Other families would need another set of patches, to solve
their problem, and so on. This scenario is totally understandable, as it
mirrors the reality that we see every day.
Now, if we take a look into first sub-category, we perhaps do not see many
examples there yet, but the number is growing. It is this sub-category given
patch intends to support. Regardless of what hardware solutions different
vendors might come up with, as long as their solutions comply with, not the
proposed patch, but the 1-step directives of IEEE 1588 V2 standard, they are
good to go with linuxptp.
Given all that, I do not see any reason for new APIs or additional features,
since everything is already in place. Proposed patch simply adds a few
additional check-points that are used to skip certain 2-step code blocks. I was
actually surprised how little code was necessary to make 1-step E2E and P2P TC
work with linuxptp. Me and my colleague have been running it for a number of
days now, and are happy with the results.
As of today, linuxptp does not support 1-step TCs at all, but the patch in
question provides a transparent solution for a given problem.
Thanks,
/Volodymyr_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
