On Wed Oct 14 2020, Richard Cochran wrote: > On Wed, Oct 14, 2020 at 12:57:47PM +0300, Vladimir Oltean wrote: >> So the discussion is about how to have the cake and eat it at the same >> time. > > And I wish for a pony. With sparkles. And a unicorn. And a rainbow. > >> Silicon vendors eager to follow the latest trends in standards are >> implementing hybrid PTP clocks, where an unsynchronizable version of the >> clock delivers MAC timestamps to the application stack, and a >> synchronizable wrapper over that same clock is what gets fed into the >> offloading engines, like the ones behind the tc-taprio and tc-gate >> offload. Some of these vendors perform cross-timestamping (they deliver >> a timestamp from the MAC with 2, or 3, or 4, timestamps, depending on >> how many PHCs that MAC has wired to it), some don't, and just deliver a >> single timestamp from a configurable source. > > Sounds like it will be nearly impossible to make a single tc-taprio > framework that fits all the hardware variants. Why? All the gate operations work on the synchronized clock. I assume all Qbv capable switches have a synchronized clock? It's just that some switches have multiple PHCs instead of a single one. It seems to be quite common to have a free-running as well as a synchronized clock. In order for a better(?) or more accurate(?) ptp implementation they expose not a single but rather multiple timestamps from all PHCs (-> cross-timestamping) to user space for the ptp event messages. That's at least my very limited understanding. > >> The operating system is supposed to ??? in order to synchronize the >> synchronizable clock to the virtual time retrieved via TIME_STATUS_NP >> that you're talking about. The question is what to replace that ??? >> with, of course. > > You have a choice. Either you synchronize the local PHC to the global > TAI time base or not. If you do synchronize the PHC, then everything > (like the globally scheduled time slots) just works. If you decide to > follow the nonsensical idea (following 802.1-AS) and leave the PHC > free running, then you will have a difficult time scheduling those > time windows. > > So it is all up to you. > >> I'm not an expert in kernel implementation either, but perhaps in the >> light of this, you can revisit the idea that kernel changes will not be >> needed (or explain more, if you still think they aren't). > > I am not opposed to kernel changes, but there must be: > > - A clear statement of the background context, and > - an explanation of the issue to solved, and > - a realistic solution that will support the wide variety of HW. Agreed. Thanks, Kurt
Attachment:
signature.asc
Description: PGP signature
