Hi Jake,
I appreciate your feedback. Yes - our hardware and most of other hardware
supports 'timestamp all' - an easier option for the software as you mention.
However, it is not always the case for different customers -
• given the encapsulations such as MPLS-TP beyond the linux supported
IPv4/6 UDP packets, we definitely need proprietary hardware for improved
parsing capabilities.
• Also, the 1-step implementation requires insertion of ToD and update of
CF at specific locations while the packets are in transit (unlike 2-step
mechanism, where the timestamps can be collected later/after the packets are
egressed). These offsets are obtained by parsing the packets inside the
hardware rather than blowing the size of the descriptors, which consumes many
cpu cycles.
• Most importantly we have witnessed two groups - generic OS based (Linux
etc) group, which prefers 'timestamp all' and proprietary OS based (network
switches, processors) group, which takes advantage of the underlying hardware
to reap the best performance (timestamping as directed by stack a subset).
Needless to say, the hardware has to support both the groups and we do that.
Thanking you in anticipation,
Regards,
Chandra
© : +60.175508142
(O): +60.4.636.6412
“Knowledge speaks, Wisdom listens”
-----Original Message-----
From: Keller, Jacob E
Sent: Saturday, April 15, 2017 12:12 AM
To: MSR, CHANDRASEKHAR <chandrasekhar....@intel.com>; Richard Cochran
<richardcoch...@gmail.com>
Cc: linuxptp-users@lists.sourceforge.net
Subject: RE: [Linuxptp-users] ptp4l stack integration via linux OS with least
burden on the Firmware and major PTP offload to the hardware
> -----Original Message-----
> From: MSR, CHANDRASEKHAR [mailto:chandrasekhar....@intel.com]
> Sent: Friday, April 14, 2017 7:48 AM
> To: Richard Cochran
> <richardcoch...@gmail.com<mailto:richardcoch...@gmail.com>>
> Cc:
> linuxptp-users@lists.sourceforge.net<mailto:linuxptp-users@lists.sourceforge.net>
> Subject: Re: [Linuxptp-users] ptp4l stack integration via linux OS
> with least burden on the Firmware and major PTP offload to the
> hardware
>
>
>
> Hi Richard,
>
> Thank you a lot for responding to my question though you could have
> easily shut me off, given the 'off topic' nature of the question. I
> need some basic clarificaions from your response.
>
> You say " IMHO this is only reasonable approach for modern MAC hardware" & "
> Nonsense. The driver must read the descriptor in any case, and it
> will only handle the time stamp if the option is enabled.". My
> confusion here is: You seem to support timestamping all the packets
> but driver will handle the timestamp if the option is enabled. If the
> driver knows whether to handle the timestamp or not through the flags
> in the DMA descriptor, then the underlying MAC hardware does take
> advantage of it so that the timestamping is carried out for the
> packets (any - ptp or nonptp), which has the option enabled. As you
> might know, the hardware usually stores the timestamps in a FIFO,
> which will be read out on polling the status or a suitable interrupt.
> With the distinction between packet needing timestamps (ptp or nonptp)
> and packet with no need of timestamps, the number of timestamps that
> can be pushed by the MAC hardware into the FIFO is limited, saving
> considerable silicon - especially the case with ASICs, where the
> depths are predetermined unlike FPGAs. Further, the driver has to wait for
> some more time after the packet is transmitted, to complete the dma ack with
> the timestamp (to be collected from the FIFO and put it back in the
> descriptor).
> However, for the packets not needing timestamps, the driver can give
> the ack quickly fetching the next set of descriptors. Thus,
> timestamping as needed by the MAC hardware is really the need of the hour
> than timestamping every packet.
> Please share your opinion.
>
> You say " It is just eight bytes, after all". Actually, it is not a PTM
> (PCIe) timestamp.
> In 1588v2, the timestamp is 10 bytes/80b. Further, our hardware
> provides even fractional nanoseconds of 16b (giving out 2^-16ns
> resolution). Understandably, the proprietary stacks have the
> capability to handle the complete 12B of timestamps than the public-domain
> stacks. Just FYI. Do share your opinion.
>
> Thank you again for sharing your expertise with us - it is very helpful.
It's certainly easier in software if all packets have a timestamp.
Additionally, I imagine it's easier in hardware if there is no special casing
since you wouldn't need any circuitry to build out how to decide which frames
get timestamped and which do not. This should be simpler. It seems to be that
yes you do pay the 8 or 16 bytes per frame if you have timestamps always, but
that cost is smaller than the huge complexity required to have the hardware
pre-determine which packet gets timestamped if it only supports a subset of
"all packets" while also forcing software to now be aware of what the hardware
will or will not timestamp.
It may be that specific hardware has limitations on how it timestamps for other
reasons, but obviously we can't comment on how the hardware is designed, since
we didn't design it. I dont think a FIFO for pushing timestamps by the MAC is
necessarily the only way to do it, and certainly lots of hardware already
suports "timestamp all packets" already today. This is a valuable feature to
software already, so if you wanted to support it then you don't need support
for any subset of all packets.
Thanks,
Jake
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
