Hi Michał,
Please see my responses inline.
Regards,
Greg
-----Original Message-----
From: Michalik, Michal <michal.micha...@intel.com>
Sent: Friday, July 29, 2022 12:25 PM
To: Greg Armstrong <greg.armstrong...@renesas.com>; richardcoch...@gmail.com
Cc: linuxptp-devel@lists.sourceforge.net; Kubalewski, Arkadiusz
<arkadiusz.kubalew...@intel.com>; Miroslav Lichvar <mlich...@redhat.com>; Erez
<erezge...@gmail.com>
Subject: RE: [Linuxptp-devel] [PATCH 00/11] synce4l: add software for
Synchronous Ethernet
Hello Greg,
Much thanks for your valuable input - we appreciate it a lot.
Please see my answers inline.
Have a great day,
Michał Michalik
> As I highlighted earlier, I, along with other users of ptp4l, don't feel the
> linuxptp project is the right place for the submission of the ITU-T ESMC
> Protocol (which is based on recommendations G.8274 & G.781). There are no
> dependencies on ESMC with the 1588 protocol or the Linux PHC, nor is the
> linuxptp maintainer wanting to be a bottleneck for contributions to the ESMC
> protocol (as highlighted below from Richard).
If you don't mind, please let me ask you a question - I am definitely missing
something. Whom are you talking about while using expression "along with other
users of ptp4l"?
**GA. We have been working with a number of PHY/SoC partners and have received
the feedback once they saw the submission to linuxptp (as they were confused).
They felt this looked like an "Intel-implementation" and should not be called
synce4l. They feel an implementation of synce4l should use a defined standard
interface pushed into the Linux kernel and not specific ones within the scope
of ptp4l. This has been the direction Renesas has been taking with our synce4l
implementation.
To my best understanding right now we have a situation, where:
- you are against including it into linuxptp,
- Miroslav Lichvar is for including it,
- Erez is for including it,
- if I understand Richard communicate well, he did not say firm "no" - just
raised
some concerns about his bandwidth,
- we (as Intel) are good with both ways - we just need to know.
In which point my understanding is faulty?
**GA. I don't think there is any fault. My concern is that an implementation
submitted to the linuxptp project may mistakenly use interfaces with the scope
of ptp4l, not allowing it to be a stand-alone protocol (which it is, as this is
an ITU-T defined protocol with no dependencies on PTP). We have several
customers who only need the ESMC protocol for their equipment.
Richard - since you obviously have the last word, would you mind to state your
final decision clearly to avoid any further interpretations of your answer?
>
> >My main concern is the fact that my time is limited to work on >linuxptp,
> >and I already have a back log of patches. If synce will have >rapid
> >development, new features, etc, then I don't want to be the >bottleneck.
>
> 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%7C0c14b6faa12f4fd3f67b08da717ee2ec%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C637947087036059280%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=jHoJi7jEC4ZxQ5fUbqVe15UPwpkmFjud2%2B%2F29RYglVQ%3D&reserved=0.
> This is an open project under GPLv2, and we welcome contributions to it. The
> implementation not only addresses the ESMC protocol per G.8264, but also
> includes some additional features from G.781. We realize there will be a need
> to provide QL and other information from synce4l to ptp4l, per applicable
> ITU-T 1588 Profiles, and look forward to collaborating with the linuxptp
> community to produce these interfaces.
Since working in community should be based on honesty, let me be honest here.
I feel we have a little awkward situation we need to solve somehow together.
Some facts about the issue I'm thinking about: We have pushed first patches of
synce4l to linuxptp newsletter on 26th May. Then we see that Renesas have
pushed one initial commit with only empty README mentioning the synce4l name
(8th Jul) and second commit with full code implementation (15th Jul) - both
commits were uploaded few weeks after our initial submission using synce4l
name. I am perfectly aware that neither of us has any trademark rights to the
name, so technically Renesas did nothing wrong. Still, we feel a little bad
about the situation where we wanted to be fair and waited for final linuxptp
community decision before pushing the synce4l somewhere else and in the
meantime see other project started with the same exact name. Let me be
perfectly clear here
**GA. Again, an implementation of "synce4l" should not concern the linuxptp
community. However, yes, we've been working on our implementation for some
time, and have already shared it with several PHY/SoC vendors as "sycne4l". We
were aware of Intel doing their own implementation as well, but when contacted,
they did not want to collaborate for what ever reason. Since this did not seem
to be "open", we continued with our development and plan to release an open
implementation of the ESMC protocol, under the name synce4l.
- I assume no bad intentions, we just have had a unfortunate coincidence here.
I assume you also have been working on this application for months and this
rush in publishing it means absolutely nothing. Let me now explain why this
name matters for us. We've been using this name internally for some time now
**GA. The "rush" was to counter your attempt to submit a patch to linuxptp. To
show there is an alternate implementation, we had to speed up our release. Our
intent was to release through the Network Time Foundation and to also have a
standard SyncE Hardware interface pushed into the Linux kernel (to more away
from any "proprietary" interface).
- it would be quite tiresome to change it in lots of documentation and
communication. Additionally, caring for best quality of our submission to
linuxptp - we have dropped our customers an early sample of synce4l last year
so they could provide us with a valuable feedback on what we could improve.
Our customers are familiar with the name synce4l and seeing other project
named the same might confuse them. Kind question - would you please at least
consider changing a project name at this very early stage?
**GA. We are likely in the same boat here, however, like I said, our other
MAC/PHY/SoC partners see your submission as an Intel implementation (since they
did not see it until you submitted the patch to linuxptp).
Before you answer that - please let me state our position. We are all part of
community and sometimes we need to find a solution somehow acceptable to all.
We are definitely open to changing our application name (within or outside
linuxptp project), even knowing that it would bring quite a big amount of
additional work.
Btw. We also considering contributing your project, if that gets more traction
and would at some time look more promising. What I am concerned about right now
looking at it, it seems really hardware specific. We aimed to avoid that at all
cost - our application is not connected to Intel HW at all - it can be used
with NIC of any vendor. Are Renesas eventually is going to do the same?
**GA. This is our intent as well, but you cannot have an implementation without
HW access to the SETS IC - and it was easier to sytart with interfaces known to
be used by Tier1 manufacturers when designing in our timing silicon. The sync
control block is a major piece of the full G.8264/G.781 solution. As I
mentioned above, our intent was to push "open" interfaces into the Linux kernel
so that the SyncE hardware was fully abstracted, similar to (but not using) the
PTP Hardware Clock. This would allow our partners to submit their own drivers
(and other timing silicon vendors to do the same).
>
> We will also be working with the Network Time Foundation to see if they would
> be willing to oversee synce4l project like the other Linux projects they
> already manage, including linuxptp. We have also already shared synce4l
> project with other MAC/PHY/SoC vendors looking for an ESMC protocol solution.
I understand - maybe a good idea is that both Intel and Renesas should change
the name, so we would not confuse anybody about 'which synce4l is which'?
**GA. We can discuss with our partners and customers, but there is no confusion
from our end since our development started as an implementation of ESMC
protocol for Linux (nothing to do with PTP). Thus, synce4l fit with our
customers (as we have some customers who only need synce4l to manage their
SyncE clock). We also were open with our partners and customers up front,
sharing the implementation as we developed. Again, we tried this with Intel and
there was no interest (Intel finally shared their implementation with Renesas
earlier this year, but we were already near the end of our own first release).
>
> Regards,
> Greg
>
> Greg Armstrong
> Principal System Architect, Timing Products Division Renesas
> Electronics Canada Limited
> Mobile: 1-613-218-9373
>
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
