Lines Matching +full:tx +full:- +full:hw +full:- +full:gso +full:- +full:packets
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
150 are only reported for packets that also have the relevant timestamp
172 have multiple concurrent timestamping requests outstanding. Packets
181 is derived from a per-socket u32 counter (that wraps). For datagram
189 change the identifiers of existing packets in the system.
204 cmsg->cmsg_level = SOL_SOCKET;
205 cmsg->cmsg_type = SCM_TS_OPT_ID;
206 cmsg->cmsg_len = CMSG_LEN(sizeof(__u32));
222 a timestamp with counter N-1. SOF_TIMESTAMPING_OPT_ID_TCP
242 Support recv() cmsg for all timestamped packets. Control messages
243 are already supported unconditionally on all packets with receive
244 timestamps and on IPv6 packets with transmit timestamp. This option
245 extends them to IPv4 packets with transmit timestamp. One use case
246 is to correlate packets with their egress device, by enabling socket
270 packets with hardware timestamps. The message contains struct
272 received the packet and its length at layer 2. A valid (non-zero)
278 Request both hardware and software timestamps for outgoing packets
290 timestamps, packets for all socket will receive timestamped packets.
297 ignore the unexpected non-zero value. But it makes behavior subtly
324 cmsg->cmsg_level = SOL_SOCKET;
325 cmsg->cmsg_type = SO_TIMESTAMPING;
326 cmsg->cmsg_len = CMSG_LEN(sizeof(__u32));
344 -------------------------
351 many packets the data has been converted into.
354 correlating a timestamp with data is non-trivial. A range of bytes
379 skbuff as a result of Nagle, cork, autocork, segmentation and GSO. The
383 relevant sequence number in skb_shinfo(skb)->tskey. Because an skbuff
392 autocork. After linux-4.7, a better way to prevent coalescing is
414 ----------------------------
437 feature. At least one field is non-zero at any time. Most timestamps
442 a HW PTP clock source, to allow time conversion in userspace and
444 as linuxptp. For the PTP clock API, see Documentation/driver-api/ptp.rst.
481 is the first if ts[2] is non-zero, the second otherwise, in which
509 Reading from the error queue is always a non-blocking operation. To
560 requested packets cannot be time stamped, then nothing should be
574 If the requested fine-grained filtering for incoming packets is not
576 of packets. ioctl(SIOCGHWTSTAMP) is used in the same way as the
581 /* possible values for hwtstamp_config->tx_type */
591 * enables hardware time stamping for outgoing packets;
599 /* possible values for hwtstamp_config->rx_filter */
607 /* return value: time stamp all packets requested plus some others */
619 --------------------------------------------------------
627 Time stamps for received packets must be stored in the skb. To get a pointer
638 Time stamps for outgoing packets are to be generated as follows:
640 - In hard_start_xmit(), check if (skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP)
641 is set no-zero. If yes, then the driver is expected to do hardware time
643 - If this is possible for the skb and requested, then declare
645 SKBTX_IN_PROGRESS in skb_shinfo(skb)->tx_flags , e.g. with::
647 skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS;
653 - Driver should call skb_tx_timestamp() as close to passing sk_buff to hardware
656 - As soon as the driver has sent the packet and/or obtained a
668 ----------------------------------------------------------
685 interface (redirecting to the host port on TX, and intercepting frames on RX).
709 - ``.port_txtstamp()``: a hook called prior to the transmission of
710 packets with a hardware TX timestamping request from user space.
711 This is required for two-step timestamping, since the hardware
714 packet so that it can re-enqueue the packet back into the socket's
717 in skb->cb and enqueue a tx skb queue. Typically, a switch will have a
718 PTP TX timestamp register (or sometimes a FIFO) where the timestamp
720 key-value pairs of PTP sequence ID/message type/domain number and the
722 packets in a queue waiting for timestamping and the actual timestamps,
728 One-step TX timestamping do not require packet cloning, since there is
729 no follow-up message required by the PTP protocol (because the
730 TX timestamp is embedded into the packet by the MAC), and therefore
731 user space does not expect the packet annotated with the TX timestamp
732 to be re-enqueued into its socket's error queue.
734 - ``.port_rxtstamp()``: On RX, the BPF classifier is run by DSA to
735 identify PTP event messages (any other packets, including PTP general
739 timestamps might either be available in-band (through metadata in the
740 DSA header, or attached in other ways to the packet), or out-of-band
751 switches do. However, PHYs may be able to detect and timestamp PTP packets, for
756 mii_timestamper`` and add a pointer to it in ``phydev->mii_ts``. The presence
764 - Checking, in ``.ndo_eth_ioctl``, whether ``phy_has_hwtstamp(netdev->phydev)``
768 - On RX, special intervention may or may not be needed, depending on the
771 ``skb_defer_rx_timestamp(skb)`` is necessary or not - and if it is, don't
773 enabled, and ``skb->dev->phydev->mii_ts`` exists, its ``.rxtstamp()`` hook
784 - On TX, again, special intervention might or might not be needed. The
785 function that calls the ``mii_ts->txtstamp()`` hook is named
806 Stacked PHCs, especially DSA (but not only) - since that doesn't require any
808 all possible code paths - is that they uncover bugs which were impossible to
812 skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS;
814 Any TX timestamping logic, be it a plain MAC driver, a DSA switch driver, a PHY
819 For example, a typical driver design for TX timestamping might be to split the
822 1. "TX": checks whether PTP timestamping has been previously enabled through
823 the ``.ndo_eth_ioctl`` ("``priv->hwtstamp_tx_enabled == true``") and the
824 current skb requires a TX timestamp ("``skb_shinfo(skb)->tx_flags &
826 "``skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS``" flag. Note: as
831 2. "TX confirmation": Transmission has finished. The driver checks whether it
832 is necessary to collect any TX timestamp for it. Here is where the typical
834 "``skb_shinfo(skb)->tx_flags & SKBTX_IN_PROGRESS``" was set. With a stacked
836 in the TX data path who could have enabled SKBTX_IN_PROGRESS in the first
840 check in their "TX confirmation" portion, not only for
841 "``skb_shinfo(skb)->tx_flags & SKBTX_IN_PROGRESS``", but also for
842 "``priv->hwtstamp_tx_enabled == true``". Because the rest of the system ensures
844 this enhanced check will avoid delivering a duplicated TX timestamp to user