It is regarding H/W Time Stamping features of XL710 40G NIC.
We are going to use XL710-QDA2(40G) MOQ - Intel® Ethernet Converged Network Adapter Dual Port Network Adapter.
We have a requirement that each RX packet(All Traffic) should be appended with H/W Time Stamp. Is it possible with this model?
From the DATA sheet, my understanding is it support IEEE 1588/PTP Time Synchronization and there is no support "Per-Packet Time Stamp" feature.
Here are my queries:
1. Is XL710 NIC supports Per-Packet H/W Time Stmaping(All RX Packets should be time stamped)?
2. In case if XL710 not supporting Per-Packet Time Stamp, is there any other mechanism/way to achieve the same from H/W level?
Pleas help me if in this regard.
Upon reading your documentation for the XL710 and the driver and the Linux Kernel ( ) , it appears that HW Timestamping exists for the XL710 on transmit. Specifically , Intel's driver uses it to implement PTP protocol in the driver file i40e_ptp.c for the Linux i40e driver. My question is a follow up to Suresh's , namely, according to the driver spec and the Linux kernel spec, if one specifies the socket option SOF_TIMESTAMPING_TX_HARDWARE ( with SO_TIMESTAMP also specified ) the timestamp is included when "the packet is provided to the Network adapter" as defined in https://www.kernel.org/doc/Documentation/networking/timestamping.txt https://www.kernel.org/doc/Documentation/networking/timestamping.txt .
My question is, this timestamping functionality, according to linuxptp.sourceforge.net, is considered to be applied at the MAC level and not the PHY. Can you let me know what that means ? Are these timestamps always incrementing for packets as they are sent out or is there the potential that these timestamps will not be "strictly increasing" for consecutive packets sent out by the XL710 NIC ?
I am working on a project that doesn't care about the packets received, only that we know the ordering of the packets sent out. If we know that two consecutive packets arriving at MAC layer will always have the first packet arriving ( and leaving ) timestamped with the lower timestamp than it's successor, then we are happy. Is this the case ?
Thank you for your feedback,