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.
>>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). >>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. >>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). **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). **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 -----Original Message----- From: Kubalewski, Arkadiusz <arkadiusz.kubalew...@intel.com> Sent: Wednesday, August 31, 2022 5:23 PM To: Miroslav Lichvar <mlich...@redhat.com>; Greg Armstrong <greg.armstrong...@renesas.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 >-----Original Message----- >From: Miroslav Lichvar mlich...@redhat.com >Sent: Thursday, August 4, 2022 11:08 AM > >On Wed, Jul 20, 2022 at 03:50:04AM +0000, Greg Armstrong wrote: >> To address this concern, Renesas has submitted our open implementation of >> the ESMC protocol to github, also under the same name: >> https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frenesas%2Fsynce4l&data=05%7C01%7Cgreg.armstrong.uw%40renesas.com%7C225abee1857f447103e708da8b970d52%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C637975778118848397%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=y90x7DrMn4mLlZGxMCE4ja4oT3OCudPWhVozrAO9zuw%3D&reserved=0. >> This is an open project under GPLv2, and we welcome contributions to it. > >I looked at the project to better understand the differences between >this and the Intel implementation. Here are my observations. > >The code doesn't build on its own. It requires "clockmatrix api", which >doesn't seem to be available without registration. > >There are some HW-specific ioctls. > >I don't see an abstraction which would allow one binary to support >different types of hardware. > >About 20% of the code comes from linuxptp (per copyright). > >-- >Miroslav Lichvar > Thanks Miroslav! 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). 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, - uses HW specific i2c to configure your NIC/timecard. Is that true? If so, do you think that it is proper way to cooperate with an open source community? 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. Should support for them be removed from linuxptp? In my humble opinion, it wouldn't make any sense. Maybe SyncE without PTP does make some sense, but for telecoms it makes most sense to use them both (if hardware supports it). 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. Richard, I know our solution in its current state is far from being perfect. It communicates with EEC by shell commands specified by the user, but at least it is not specific for any particular hardware. Although it doesn't configure EEC, as it shall be preconfigured before using our solution. Our next steps would be: - introduce in-kernel interface which allows control of EEC, - implement a user-space tool for configuration of EEC using new in-kernel interface, - add support for EEC "get lock status"/"set source" in our solution and Replace shell commands - add support for getting EEC info for Telecom profiles in our solution. Could you please decide if there is a room for this solution in linuxptp, assuming we will review and ACK all the future patches on the SyncE part, and help to maintain it as long as it needs support? We are planning to help extending ptp4l with the interface to interoperate with synce4l (and other similar tools, including Renesas implementation). Also, if you think that it would be better to have it in separated project, please let us know, as we need to upstream it somewhere due to customer requests. Thank you, Arkadiusz _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
