[Linuxptp-users] ptp4l stack integration via linux OS with least burden on the Firmware and major PTP offload to the hardware

[MSR, C. <cha...@in...>]

Hi Friends,

I am lost in visualizing a proper system with ptp4l on our hardware that supports linux along with hardware timestamping. Could you help bring some clarity on my following question? Please note that I am a systems architect and a linux expert and thus the following flow is a generic one. Please fill in the gaps from the linux perspective, if you see any. Appreciate your help on this long thread.

Ptp4l stack generates the sync packets - can be layer 2, layer3 (ipv4/6) with UDP etc. Each packet gets a set of skbufs + 1 more skbuf for associating the corresponding timestamp from the hardware to complete the dma flow for a ptp packet. Now, these sync packets come along with other regular Ethernet, IP packets, which donot need the extra skbuf for timestamp purpose. The hardware (DMA+PTP packet parser + MAC+Phy) has the capability to timestamp only the PTP packets. Now, WITHOUT LOADING THE DRIVER/FIRMWARE (the driver should not parse the packets to know whether they are ptp or non-ptp regular packets), can I have the capability to assign an extra skbuf for a ptp packet to associate the timestamp with the packet's DMA flow? In other words, the non-ptp packets will be parsed accordingly in the hardware without generating any timestamps and thus their DMA flow (considering tx) will terminate with no the extra skbuf (not needed as they donot generate timestamps in the hardware). Given this scenario,

How does the driver know for which packet, it should complete the dma flow by waiting for the timestamp and associating it with the extra skbuf? If we can have this driven by the respective application (ptp4l for ptp packets and tcp/udp apps for regular non-ptp traffic) in a way that the firmware/driver knows about it easily without any burdensome operation such as parsing, it is very efficient (more traffic on ethernet link). More importantly, the underlying hardware does the tougher job of producing timestamps for only the necessary packets.

A simple solution is timestamping all the packets and making the dma flow uniform to all the packets - ptp and non-ptp regular packets, where each packet's timestamp whether needed or not for the ptp4l stack will be stored in the hardware fifo. It can lead to overflow due to slower turnaround from the driver or in the worst case slow down the link losing the throughput.

My preferred solution: The DMA header has a control bit that clearly tells PTP or non-PTP packet. The firmware has two threads - mac and ptp. Now the contro bit determins which thread has to complete the dma flow. For example, for a non-ptp packet, the mac driver will complete the DMA flow by sending the status back without any timestamp in it (prefer to have no bytes allocated for the timestamp at all). For a ptp packet, the ptp driver will complete the DMA flow by sending the final status back to the DMA driver by inserting the timestamp (extra bytes present in the DMA status word) in the status word. The ptp driver knows that it has to read the status register to check whether the PTP packet's timestamp is ready in the FIFO. However, the mac driver does not even bother about this and will complete sending its status quickly. I see no sequential requirements of packet status for the DMA completion between ptp and non-ptp packets. I feel this is very efficient and faster, enabling the highest throughput on the Ethernet link and achieving the objective that the PTP flow should anyway utilize the link to the absolute minimum required and be least intrusive to the regular non-PTP flow.

Thanking you in anticipation,
Regards,
Chandra

(c) : +60.175508142
(O): +60.4.636.6412

"Knowledge speaks, Wisdom listens"