On Thu, Dec 03, 2020 at 05:35:09PM +0100, Volodymyr Bendiuga wrote: > 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.
So it works almost like dpaa2, except that your hardware is clever enough to search for t1 where it knows it put it, whereas dpaa2 has the concept of a t_passed_inband which can be supplied by the driver from any source, including from the reserved fields. So dpaa2 is more generic than your Marvell PHY. > 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. So, coming back to my comment about boundary_clock_jbod=1. The generic solution will not work if you have a one-step TC build out of a Marvell 88E1548P on ingress and a TI PHYTER on egress. They both have the same idea, but it's the specifics that kill the implementation. We need to specify very clearly where t1 should be kept. It's almost as if we should declare some of the reserved fields of the PTP header as "implementation specific for linuxptp". This would be hard ABI that is set in stone. I think it's clear that the correctionField is not going to be enough for this. > 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. Come on... > 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. Why would linuxptp even attempt to drive hardware that is not fully compliant to the requirements of IEEE 1588? I don't understand..... > 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. I am absolutely confused how you declare that a software-assisted TC falls in bucket 1 (fully compliant with the spec) or bucket 2 (partly compliant with the spec). Please give an example. > 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. Wrong. Nothing is in place. Not even the convention. And no driver uses a convention that doesn't yet exist, of course. _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
