Documentation/networking/timestamping.rst

1 .. SPDX-License-Identifier: GPL-2.0
43 -------------------------------------------------------------
47 the network stack, the feature has to be enabled for all packets. The
59 -------------------------------------------------------------------
72 ----------------------------------------------------------------------
93 created packets, not to packets already in the stack. As a result, it
94 is possible to selectively request timestamps for a subset of packets
110   Request tx timestamps generated by the network adapter. This flag
114   Request tx timestamps when data leaves the kernel. These timestamps
121   Request tx timestamps prior to entering the packet scheduler. Kernel
135   Request tx timestamps when all data in the send buffer has been
138   over-report measurement, because the timestamp is generated when all
144   Request tx timestamps on packet tx completion.  The completion
147   packets at once, and completion timestamps reflect the timing of the
148   report and not actual tx time. This flag can be enabled via both
158 are only reported for packets that also have the relevant timestamp
180   have multiple concurrent timestamping requests outstanding. Packets
189   is derived from a per-socket u32 counter (that wraps). For datagram
197   change the identifiers of existing packets in the system.
212     cmsg->cmsg_level		 = SOL_SOCKET;
213     cmsg->cmsg_type		 = SCM_TS_OPT_ID;
214     cmsg->cmsg_len		 = CMSG_LEN(sizeof(__u32));
230   a timestamp with counter N-1. SOF_TIMESTAMPING_OPT_ID_TCP
250   Support recv() cmsg for all timestamped packets. Control messages
251   are already supported unconditionally on all packets with receive
252   timestamps and on IPv6 packets with transmit timestamp. This option
253   extends them to IPv4 packets with transmit timestamp. One use case
254   is to correlate packets with their egress device, by enabling socket
278   packets with hardware timestamps. The message contains struct
280   received the packet and its length at layer 2. A valid (non-zero)
286   Request both hardware and software timestamps for outgoing packets
298   timestamps, packets for all socket will receive timestamped packets.
305   ignore the unexpected non-zero value. But it makes behavior subtly
332   cmsg->cmsg_level	       = SOL_SOCKET;
333   cmsg->cmsg_type	       = SO_TIMESTAMPING;
334   cmsg->cmsg_len	       = CMSG_LEN(sizeof(__u32));
352 -------------------------
359 many packets the data has been converted into.
362 correlating a timestamp with data is non-trivial. A range of bytes
387 skbuff as a result of Nagle, cork, autocork, segmentation and GSO. The
391 relevant sequence number in skb_shinfo(skb)->tskey. Because an skbuff
400 autocork. After linux-4.7, a better way to prevent coalescing is
422 ----------------------------
445 feature. At least one field is non-zero at any time. Most timestamps
450 a HW PTP clock source, to allow time conversion in userspace and
452 as linuxptp. For the PTP clock API, see Documentation/driver-api/ptp.rst.
489 is the first if ts[2] is non-zero, the second otherwise, in which
517 Reading from the error queue is always a non-blocking operation. To
568 requested packets cannot be time stamped, then nothing should be
582 If the requested fine-grained filtering for incoming packets is not
584 of packets. ioctl(SIOCGHWTSTAMP) is used in the same way as the
589     /* possible values for hwtstamp_config->tx_type */
599 	    * enables hardware time stamping for outgoing packets;
607     /* possible values for hwtstamp_config->rx_filter */
615 	    /* return value: time stamp all packets requested plus some others */
627 --------------------------------------------------------
635 Time stamps for received packets must be stored in the skb. To get a pointer
646 Time stamps for outgoing packets are to be generated as follows:
648 - In hard_start_xmit(), check if (skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP)
649   is set no-zero. If yes, then the driver is expected to do hardware time
651 - If this is possible for the skb and requested, then declare
653   SKBTX_IN_PROGRESS in skb_shinfo(skb)->tx_flags , e.g. with::
655       skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS;
661 - Driver should call skb_tx_timestamp() as close to passing sk_buff to hardware
664 - As soon as the driver has sent the packet and/or obtained a
676 ----------------------------------------------------------
693 interface (redirecting to the host port on TX, and intercepting frames on RX).
717 - ``.port_txtstamp()``: a hook called prior to the transmission of
718   packets with a hardware TX timestamping request from user space.
719   This is required for two-step timestamping, since the hardware
722   packet so that it can re-enqueue the packet back into the socket's
725   in skb->cb and enqueue a tx skb queue. Typically, a switch will have a
726   PTP TX timestamp register (or sometimes a FIFO) where the timestamp
728   key-value pairs of PTP sequence ID/message type/domain number and the
730   packets in a queue waiting for timestamping and the actual timestamps,
736   One-step TX timestamping do not require packet cloning, since there is
737   no follow-up message required by the PTP protocol (because the
738   TX timestamp is embedded into the packet by the MAC), and therefore
739   user space does not expect the packet annotated with the TX timestamp
740   to be re-enqueued into its socket's error queue.
742 - ``.port_rxtstamp()``: On RX, the BPF classifier is run by DSA to
743   identify PTP event messages (any other packets, including PTP general
747   timestamps might either be available in-band (through metadata in the
748   DSA header, or attached in other ways to the packet), or out-of-band
759 switches do. However, PHYs may be able to detect and timestamp PTP packets, for
764 mii_timestamper`` and add a pointer to it in ``phydev->mii_ts``. The presence
772 - Checking, in ``.ndo_eth_ioctl``, whether ``phy_has_hwtstamp(netdev->phydev)``
776 - On RX, special intervention may or may not be needed, depending on the
779   ``skb_defer_rx_timestamp(skb)`` is necessary or not - and if it is, don't
781   enabled, and ``skb->dev->phydev->mii_ts`` exists, its ``.rxtstamp()`` hook
792 - On TX, again, special intervention might or might not be needed.  The
793   function that calls the ``mii_ts->txtstamp()`` hook is named
818       skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS;
820 Any TX timestamping logic, be it a plain MAC driver, a DSA switch driver, a PHY
825 For example, a typical driver design for TX timestamping might be to split the
828 1. "TX": checks whether PTP timestamping has been previously enabled through
829    the ``.ndo_eth_ioctl`` ("``priv->hwtstamp_tx_enabled == true``") and the
830    current skb requires a TX timestamp ("``skb_shinfo(skb)->tx_flags &
832    "``skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS``" flag. Note: as
837 2. "TX confirmation": Transmission has finished. The driver checks whether it
838    is necessary to collect any TX timestamp for it. Here is where the typical
840    "``skb_shinfo(skb)->tx_flags & SKBTX_IN_PROGRESS``" was set. With a stacked
842    in the TX data path who could have enabled SKBTX_IN_PROGRESS in the first
846 check in their "TX confirmation" portion, not only for
847 "``skb_shinfo(skb)->tx_flags & SKBTX_IN_PROGRESS``", but also for
848 "``priv->hwtstamp_tx_enabled == true``". Because the rest of the system ensures
850 this enhanced check will avoid delivering a duplicated TX timestamp to user