Lines Matching +full:recv +full:- +full:not +full:- +full:empty
1 .. SPDX-License-Identifier: GPL-2.0
14 Generates a timestamp for each incoming packet in (not necessarily
43 -------------------------------------------------------------
46 path. Because the destination socket, if any, is not known early in
59 -------------------------------------------------------------------
72 ----------------------------------------------------------------------
75 socket option takes a bitmap of flags, not a boolean. In::
80 bit returns EINVAL and does not change the current state.
93 created packets, not to packets already in the stack. As a result, it
117 require driver support and may not be available for all devices.
138 over-report measurement, because the timestamp is generated when all
175 queue out of order from the original send() calls. It is not always
181 is derived from a per-socket u32 counter (that wraps). For datagram
188 enabled after having been disabled. Resetting the counter does not
201 not entirely trivial. This option fixes that.
208 a timestamp with counter N-1. SOF_TIMESTAMPING_OPT_ID_TCP
220 not affected by external inputs.
228 Support recv() cmsg for all timestamped packets. Control messages
238 timestamp as a cmsg alongside an empty packet, as opposed to
258 received the packet and its length at layer 2. A valid (non-zero)
279 do not request receive timestamp generation. This can happen when
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
369 relevant sequence number in skb_shinfo(skb)->tskey. Because an skbuff
378 autocork. After linux-4.7, a better way to prevent coalescing is
383 itself does not reorder the segments. The stack indeed tries to avoid
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.
467 is the first if ts[2] is non-zero, the second otherwise, in which
483 The calling application is often not interested in receiving the whole
495 Reading from the error queue is always a non-blocking operation. To
507 on a normal recvmsg(). Since this is not a socket error, it is not
531 the requested fine-grained filtering for incoming packets is not
546 indicates that SIOCSHWTSTAMP is not supported at all).
554 not been implemented in all drivers.
558 /* possible values for hwtstamp_config->tx_type */
576 /* possible values for hwtstamp_config->rx_filter */
596 --------------------------------------------------------
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;
626 and not free the skb. A driver not supporting hardware time stamping doesn't
629 - Driver should call skb_tx_timestamp() as close to passing sk_buff to hardware
631 and hardware timestamping is not possible (SKBTX_IN_PROGRESS not set).
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
644 ----------------------------------------------------------
671 I/O, they do have their own PHC). It is typical, but not mandatory, for all
674 By design, PTP timestamping with a DSA switch does not need any special
678 hardware timestamping on it. This is because the SO_TIMESTAMPING API does not
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
707 user space does not expect the packet annotated with the TX timestamp
708 to be re-enqueued into its socket's error queue.
710 - ``.port_rxtstamp()``: On RX, the BPF classifier is run by DSA to
712 messages, are not timestamped). The original (and only) timestampable
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
726 hence they do not have a representation in terms of a network interface as DSA
732 mii_timestamper`` and add a pointer to it in ``phydev->mii_ts``. The presence
735 Since PHYs do not have network interface representations, the timestamping and
740 - Checking, in ``.ndo_eth_ioctl``, whether ``phy_has_hwtstamp(netdev->phydev)``
741 is true or not. If it is, then the MAC driver should not process this request
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
757 ``skb_defer_rx_timestamp()`` is necessary, so this check is not needed inside
760 - On TX, again, special intervention might or might not be needed. The
761 function that calls the ``mii_ts->txtstamp()`` hook is named
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
804 never trigger, as this MAC is certainly not the outermost PHC. But this is
805 not where the typical issue is. Transmission proceeds with this packet.
810 "``skb_shinfo(skb)->tx_flags & SKBTX_IN_PROGRESS``" was set. With a stacked
811 PHC system, this is incorrect because this MAC driver is not the only entity
816 check in their "TX confirmation" portion, not only for
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
819 that PTP timestamping is not enabled for anything other than the outermost PHC,