Documentation/networking/timestamping.rst

1 .. SPDX-License-Identifier: GPL-2.0
43 -------------------------------------------------------------
59 -------------------------------------------------------------------
72 ----------------------------------------------------------------------
97 Timestamps may also be generated for reasons other than being
102   Request rx timestamps generated by the network adapter.
106   are generated just after a device driver hands a packet to the
110   Request tx timestamps generated by the network adapter. This flag
115   are generated in the device driver as close as possible, but always
130   a timestamp is generated at each layer. This allows for fine
138   over-report measurement, because the timestamp is generated when all
148 generated control message. Changes to the bits take immediate
154   Report any software timestamps when available.
160   Report hardware timestamps as generated by
181   is derived from a per-socket u32 counter (that wraps). For datagram
208   a timestamp with counter N-1. SOF_TIMESTAMPING_OPT_ID_TCP
258   received the packet and its length at layer 2. A valid (non-zero)
264   Request both hardware and software timestamps for outgoing packets
266   are enabled at the same time. If both timestamps are generated,
274   Receive timestamps are generated early in the ingress path, before a
283   ignore the unexpected non-zero value. But it makes behavior subtly
310   cmsg->cmsg_level	       = SOL_SOCKET;
311   cmsg->cmsg_type	       = SO_TIMESTAMPING;
312   cmsg->cmsg_len	       = CMSG_LEN(sizeof(__u32));
330 -------------------------
340 correlating a timestamp with data is non-trivial. A range of bytes
358 bytestreams, we chose that a timestamp is generated only when all
369 relevant sequence number in skb_shinfo(skb)->tskey. Because an skbuff
370 has only one such field, only one timestamp can be generated.
378 autocork. After linux-4.7, a better way to prevent coalescing is
381 These precautions ensure that the timestamp is generated only when all
395 page (`man 7 socket`) describes how timestamps generated with
400 ----------------------------
423 feature. At least one field is non-zero at any time. Most timestamps
430 as linuxptp. For the PTP clock API, see Documentation/driver-api/ptp.rst.
434 software timestamp will be generated in the recvmsg() call and passed
435 in ts[0] when a real software timestamp is missing. This happens also
467 is the first if ts[2] is non-zero, the second otherwise, in which
495 Reading from the error queue is always a non-blocking operation. To
510 implicitly defined. ts[0] holds a software timestamp if set, ts[1]
531 the requested fine-grained filtering for incoming packets is not
558     /* possible values for hwtstamp_config->tx_type */
576     /* possible values for hwtstamp_config->rx_filter */
596 --------------------------------------------------------
614 Time stamps for outgoing packets are to be generated as follows:
616 - In hard_start_xmit(), check if (skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP)
617   is set no-zero. If yes, then the driver is expected to do hardware time
619 - If this is possible for the skb and requested, then declare
621   SKBTX_IN_PROGRESS in skb_shinfo(skb)->tx_flags , e.g. with::
623       skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS;
628   software generated time stamps by the network subsystem.
629 - Driver should call skb_tx_timestamp() as close to passing sk_buff to hardware
630   as possible. skb_tx_timestamp() provides a software time stamp if requested
632 - As soon as the driver has sent the packet and/or obtained a
638   should not fall back to software time stamping. The rationale is that
640   software time stamping and therefore could lead to unexpected deltas
644 ----------------------------------------------------------
685 - ``.port_txtstamp()``: a hook called prior to the transmission of
687   This is required for two-step timestamping, since the hardware
690   packet so that it can re-enqueue the packet back into the socket's
693   in skb->cb and enqueue a tx skb queue. Typically, a switch will have a
696   key-value pairs of PTP sequence ID/message type/domain number and the
704   One-step TX timestamping do not require packet cloning, since there is
705   no follow-up message required by the PTP protocol (because the
708   to be re-enqueued into its socket's error queue.
710 - ``.port_rxtstamp()``: On RX, the BPF classifier is run by DSA to
715   timestamps might either be available in-band (through metadata in the
716   DSA header, or attached in other ways to the packet), or out-of-band
732 mii_timestamper`` and add a pointer to it in ``phydev->mii_ts``. The presence
740 - Checking, in ``.ndo_eth_ioctl``, whether ``phy_has_hwtstamp(netdev->phydev)``
744 - On RX, special intervention may or may not be needed, depending on the
747   ``skb_defer_rx_timestamp(skb)`` is necessary or not - and if it is, don't
749   enabled, and ``skb->dev->phydev->mii_ts`` exists, its ``.rxtstamp()`` hook
760 - On TX, again, special intervention might or might not be needed.  The
761   function that calls the ``mii_ts->txtstamp()`` hook is named
765   drivers already perform for software timestamping purposes. Therefore, if a
766   MAC supports software timestamping, it does not need to do anything further
782 Stacked PHCs, especially DSA (but not only) - since that doesn't require any
784 all possible code paths - is that they uncover bugs which were impossible to
788       skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS;
799    the ``.ndo_eth_ioctl`` ("``priv->hwtstamp_tx_enabled == true``") and the
800    current skb requires a TX timestamp ("``skb_shinfo(skb)->tx_flags &
802    "``skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS``" flag. Note: as
810    "``skb_shinfo(skb)->tx_flags & SKBTX_IN_PROGRESS``" was set. With a stacked
817 "``skb_shinfo(skb)->tx_flags & SKBTX_IN_PROGRESS``", but also for
818 "``priv->hwtstamp_tx_enabled == true``". Because the rest of the system ensures