>-----Original Message----- >From: Greg Armstrong <greg.armstrong...@renesas.com> >Sent: Friday, September 2, 2022 7:08 PM >To: Kubalewski, Arkadiusz <arkadiusz.kubalew...@intel.com>; Miroslav Lichvar ><mlich...@redhat.com>; Richard Cochran <richardcoch...@gmail.com>; Michalik, >Michal <michal.micha...@intel.com> >Cc: Kwapulinski, Piotr <piotr.kwapulin...@intel.com>; Sawula, Andrzej ><andrzej.saw...@intel.com>; linuxptp-devel@lists.sourceforge.net; Gerasymenko, >Anatolii <anatolii.gerasyme...@intel.com> >Subject: RE: [Linuxptp-devel] [PATCH 00/11] synce4l: add software for >Synchronous Ethernet > >Hi Arkadiusz, > >>>I assume that silence on this thread (from the rest of the members), same as >>>silence on any other community mailing list thread, is actually a quiet >>>approval (or at least no one has any objections). >**GA. I do not feel this way - lack oresponse is likely an indication of lack >of expertise to review impact to linuxptp - or if your implementation even is >compliant to G.8264/G.781 (feel free to contact me outsider of this if you >want feedback based on our understanding of G.8264 & G.781). You are adding a >new feature/protocol to the linuxptp project, which is overseen by the Network >Time Foundation. Thus, I will let them comment if they will allow this.
This is not about feelings, but about open source community cooperation. It is initial implementation, It would be great to have this compliant with G.8264/G.781 in 100%, but in time it will get so. I am sure you have heared about iterative development. Why do you say that linuxptp community doesn't have expertise to review the impact on linuxptp? Who else would have? Network Time Foundation supports this project, but it doesn't own it? Not sure why you are trying to imply a narration, where they would have agree on this. Community interested in linuxptp development must agree on this, basing on their expertise in Linux, Timesync domain, tools usage and their development. Protocol of 1588 is not changed with our patches, and it is not your sole decision where the SyncE protocol belongs. Everyone interested in this thread already knows your opinion, the question is if others backup this opinion or not. > >>>Greg, >>>You are saying that your project is open source, and you would welcome >>>contribution to it, but at the same time seems that your code: >>>- requires third party proprietary module for compilation, >**GA. This has already been fixed. However, this is not the right forum to >debate ESMC projects - my objection to your patch is an implementation of the >ESMC protocol does not belong in the linuxptp project; as it has nothing to do >with the 1588 standard. The focus on this project should be on PTP, it's >Profiles, and any application that makes use of the PHC (i.e. ts2phc, pmc, >phc2sys) - none of this applies to ESMC protocol. > >>>- uses HW specific i2c to configure your NIC/timecard. >>>Is that true? >**GA. Of course you need an interface to HW, how else are you allowing the >ESMC protocol to "manage" the SyncE clock as an ITU-T compliant node. That is >the limitation of your implementation, as you make a lot of assumptions of a >"fixed" configuration of the HW - if the HW is fixed, why would you need a >protocol to manage it? > >**GA. Again, no one is arguing you need a HW abstraction for the ESMC protocol >to manage the local SyncE clock node. All ESMC implementation I have seen so >far have not addressed this in the linux Kernel - but they all claim that is >the long-term goal; which is good. What I don't want is someone thinking it >should be added to the PHC, as the PHC is "not" for SyncE HW clock. The only >applicable interface I could envision for the PHC is to allow for the Local >Clock section for the Local PTP Clock (i.e. XO/XTAL vs SyncE). Protocol is mostly about handling ESMC frames and reacting on it. We managed to do such HW abstraction, right now we are also working to make synce4l control all the available sources (together with external ones). I understand your implementation works only with your device, our with any device. Not saying about future, it works right now. > >>>If so, do you think that it is proper way to cooperate with an open source >>>community? >**GA. Again, this is off topic so I will not address here. Please feel free to >send me an email directly. > >>>Excuses me but I hardly understand what you would like to achieve except >>>blocking delivery of this solution. As I see it, your only argument is that >>>SyncE is not a part of 1588. Well sure, SyncE is only mentioned in >>>appendices, but you know, Telecom Profiles are not part of 1588, they are >>>only >>>mentioned in appendices. >**GA. It's unfortunate you feel this way. Renesas has been a long-time member >of ITU-T and also of OCP. Yes, we are blocking a patch to add an unrelated >protocol to an implementation of a PTP protocol, as it does not belong in this >project - as most members of the linuxptp community do not have the background >or expertise to review contributions to an ESMC implementation. However, >adding support for 1588 Profiles, as allowed by the 1588 standard, makes >complete sense. It also makes sense to put in supporting SW of "PTP", since >it's also interfacing the PHC (i.e. ts2phc, phc2sys). I don't think anyone is >suggesting not allowing Profile support to be patch to the linuxptp project. Well, thanks for your opinion. For me, it makes sense when SW is used by someone, if this Telecom profiles are used by linuxptp users, it would be easiest for them to use SyncE from one place and for developers to implement it. > >>>Should support for them be removed from linuxptp? >>>In my humble opinion, it wouldn't make any sense. >**GA. No, it would not make sense to remove an interface between PTP and ESMC, >but it should be just that - an interface. If you want to focus your patch to >this interface, then please submit that to the linuxptp project. > >>>Maybe SyncE without PTP does make some sense, but for telecoms it makes most >>>sense to use them both (if hardware supports it). >**GA. And I have arguments of only needed ESMC. Again, not saying there will >not be an interface between the two protocols, but contributions to either >protocol as part of the implementation are mutually exclusive - as they are >applicable to independent clocks as defined by the ITU-T. > >>>Following this idea, it makes most sense to have both in the same package, as >>>for full support of "Annex L" (1588), the SyncE daemon shall provide data to >>>the PTP daemon. It is easiest to maintain both applications in one >>>repository, >>>this prevents any incompatibility issues between shared interfaces. >**GA. An argument of code reuse is not valid to submit code to an unrelated >project. The ESMC protocol has absolutely no dependencies on PTP or the PHC. >The Annex was put in to address the high accuracy profile, which was new in >1588-2019. Again, it does not suggest using the ITU-T concept of SyncE (in >fact, HA Profile recommends using a coherent, congruent physical layer clock >managed by PTP itself - referenced as L1Sync). Code reuse is minimal, we want to have them together for sake of users and developers. Synchronous Ethernet is mentioned in the Annex, so this is actually a kind of suggestion? > >**GA. You are correct the ITU-T G.8275.1 Profile recommends the use of >physical layer "assistance" (and G.8275.2, as optional) - but to be clear, >it's assisting the local PTP clock, it is not managing the PTP clock nor does >the PTP protocol have any influence on the ESMC protocol/SyncE clock. Thus, >Annex L in 1588 is not applicable for the ITU-T Profiles (nor is it referenced >by either profile) - as ITU-T assumes the physical layer clock is managed by >the ESMC protocol (not PTP, so does not use L1Sync). In my opinion it could fit linuxptp, your is different. That's all. > >**GA. Again, my push back is that any implementation of the ESMC protocol does >not belong in the linuxptp project. Instead, the community should focus on how >to interface to the ESMC to meet the recommendations of the applicable 1588 >Profiles (i.e. ITU-T). And for those profiles that use L1Sync (i.e. HA >Profile), by all means, this belongs in linuxptp project as it's part of PTP >(and in this case, the L1Sync interface is likely going through PHC) - but >please don't confuse this with ITU-T's SyncE as they are not related. > >Regards, >Greg > >Greg Armstrong >Principal System Architect, Timing Products Division >Renesas Electronics Canada Limited >Mobile: 1-613-218-9373 > > Again, thanks for your opinion. Thank you, Arkadiusz _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
