Lines Matching +full:over +full:- +full:sampling

84 (e.g., for sampling) by embedding an send() call within two setsockopt
128   over-report measurement, because the timestamp is generated when all
169   is derived from a per-socket u32 counter (that wraps). For datagram
220   received the packet and its length at layer 2. A valid (non-zero)
255   cmsg->cmsg_level	       = SOL_SOCKET;
256   cmsg->cmsg_type	       = SO_TIMESTAMPING;
257   cmsg->cmsg_len	       = CMSG_LEN(sizeof(__u32));
284 correlating a timestamp with data is non-trivial. A range of bytes
313 relevant sequence number in skb_shinfo(skb)->tskey. Because an skbuff
364 feature. At least one field is non-zero at any time. Most timestamps
371 as linuxptp. For the PTP clock API, see Documentation/driver-api/ptp.rst.
406 is the first if ts[2] is non-zero, the second otherwise, in which
431 Reading from the error queue is always a non-blocking operation. To
465 the requested fine-grained filtering for incoming packets is not
490 /* possible values for hwtstamp_config->tx_type */
508 /* possible values for hwtstamp_config->rx_filter */
546 - In hard_start_xmit(), check if (skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP)
547   is set no-zero. If yes, then the driver is expected to do hardware time
549 - If this is possible for the skb and requested, then declare
551   SKBTX_IN_PROGRESS in skb_shinfo(skb)->tx_flags , e.g. with
553       skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS;
559 - Driver should call skb_tx_timestamp() as close to passing sk_buff to hardware
562 - As soon as the driver has sent the packet and/or obtained a