Lines Matching refs:timestamp
14 Generates a timestamp for each incoming packet in (not necessarily
15 monotonic) system time. Reports the timestamp via recvmsg() in a
25 timestamp as struct timespec in nsec resolution.
33 Only for multicast:approximate transmit timestamp obtained by
34 reading the looped packet receive timestamp.
38 multiple timestamp sources, including hardware. Supports generating
48 same is true for all early receive timestamp options.
52 Always use SO_TIMESTAMP_NEW timestamp to always get timestamp in
65 Always use SO_TIMESTAMPNS_NEW timestamp to always get timestamp in
74 Supports multiple types of timestamp requests. As a result, this
82 The socket option configures timestamp generation for individual
83 sk_buffs (1.3.1), timestamp reporting to the socket's error
96 calls, one to enable timestamp generation and one to disable it.
123 difference between this timestamp and one taken at
127 timestamp taken immediately before send() from this timestamp. On
130 a timestamp is generated at each layer. This allows for fine
138 over-report measurement, because the timestamp is generated when all
149 effect at the timestamp reporting locations in the stack. Timestamps
150 are only reported for packets that also have the relevant timestamp
177 based on timestamp order or payload inspection alone, then.
180 identifier and returns that along with the timestamp. The identifier
192 timestamp is always looped along with a struct sock_extended_err.
194 among all possibly concurrently outstanding timestamp requests for
222 a timestamp with counter N-1. SOF_TIMESTAMPING_OPT_ID_TCP
244 timestamps and on IPv6 packets with transmit timestamp. This option
245 extends them to IPv4 packets with transmit timestamp. One use case
252 timestamp as a cmsg alongside an empty packet, as opposed to
255 the timestamp even if sysctl net.core.tstamp_allow_data is 0.
261 transmit timestamp is available, the stats are available in a
282 each containing just one timestamp.
285 Filter out spurious receive timestamps: report a receive timestamp
286 only if the matching timestamp generation flag is enabled.
291 Including those that request timestamp reporting with
293 do not request receive timestamp generation. This can happen when
315 In addition to socket options, timestamp generation can be requested
335 Moreover, applications must still enable timestamp reporting via
354 correlating a timestamp with data is non-trivial. A range of bytes
368 bytestream consistently, if both semantics of the timestamp and the
372 bytestreams, we chose that a timestamp is generated only when all
384 has only one such field, only one timestamp can be generated.
386 In rare cases, a timestamp request can be missed if two requests are
389 send time with the value returned for each timestamp. It can prevent
395 These precautions ensure that the timestamp is generated only when all
396 bytes have passed a timestamp point, assuming that the network stack
430 Always use SO_TIMESTAMPING_NEW timestamp to always get timestamp in
448 software timestamp will be generated in the recvmsg() call and passed
449 in ts[0] when a real software timestamp is missing. This happens also
456 socket's error queue with the send timestamp(s) attached. A process
474 type SCM_TSTAMP_* to define the actual timestamp passed in
482 case the timestamp is stored in ts[0].
499 error queue mechanism is just a method to piggyback the timestamp on.
510 block waiting on a timestamp, use poll or select. poll() will return
524 implicitly defined. ts[0] holds a software timestamp if set, ts[1]
525 is again deprecated and ts[2] holds a hardware timestamp if set.
702 timestamp becomes available after the actual MAC transmission, so the
703 driver must be prepared to correlate the timestamp with the original
705 error queue. To save the packet for when the timestamp becomes
708 PTP TX timestamp register (or sometimes a FIFO) where the timestamp
711 actual timestamp. To perform the correlation correctly between the
716 timestamp's availability, or the driver might have to poll after
720 TX timestamp is embedded into the packet by the MAC), and therefore
721 user space does not expect the packet annotated with the TX timestamp
727 skb is provided to the driver, for it to annotate it with a timestamp,
732 necessary when retrieving the timestamp needs a sleepable context. In
741 switches do. However, PHYs may be able to detect and timestamp PTP packets, for
767 timestamp is available.
808 timestamp.
814 current skb requires a TX timestamp ("``skb_shinfo(skb)->tx_flags &
822 is necessary to collect any TX timestamp for it. Here is where the typical
834 this enhanced check will avoid delivering a duplicated TX timestamp to user