Documentation/networking/timestamping.txt

   1
   2 1. Control Interfaces
   3
   4 The interfaces for receiving network packages timestamps are:
   5
   6 * SO_TIMESTAMP
   7   Generates a timestamp for each incoming packet in (not necessarily
   8   monotonic) system time. Reports the timestamp via recvmsg() in a
   9   control message as struct timeval (usec resolution).
  10
  11 * SO_TIMESTAMPNS
  12   Same timestamping mechanism as SO_TIMESTAMP, but reports the
  13   timestamp as struct timespec (nsec resolution).
  14
  15 * IP_MULTICAST_LOOP + SO_TIMESTAMP[NS]
  16   Only for multicast:approximate transmit timestamp obtained by
  17   reading the looped packet receive timestamp.
  18
  19 * SO_TIMESTAMPING
  20   Generates timestamps on reception, transmission or both. Supports
  21   multiple timestamp sources, including hardware. Supports generating
  22   timestamps for stream sockets.
  23
  24
  25 1.1 SO_TIMESTAMP:
  26
  27 This socket option enables timestamping of datagrams on the reception
  28 path. Because the destination socket, if any, is not known early in
  29 the network stack, the feature has to be enabled for all packets. The
  30 same is true for all early receive timestamp options.
  31
  32 For interface details, see `man 7 socket`.
  33
  34
  35 1.2 SO_TIMESTAMPNS:
  36
  37 This option is identical to SO_TIMESTAMP except for the returned data type.
  38 Its struct timespec allows for higher resolution (ns) timestamps than the
  39 timeval of SO_TIMESTAMP (ms).
  40
  41
  42 1.3 SO_TIMESTAMPING:
  43
  44 Supports multiple types of timestamp requests. As a result, this
  45 socket option takes a bitmap of flags, not a boolean. In
  46
  47   err = setsockopt(fd, SOL_SOCKET, SO_TIMESTAMPING, &val, sizeof(val));
  48
  49 val is an integer with any of the following bits set. Setting other
  50 bit returns EINVAL and does not change the current state.
  51
  52 The socket option configures timestamp generation for individual
  53 sk_buffs (1.3.1), timestamp reporting to the socket's error
  54 queue (1.3.2) and options (1.3.3). Timestamp generation can also
  55 be enabled for individual sendmsg calls using cmsg (1.3.4).
  56
  57
  58 1.3.1 Timestamp Generation
  59
  60 Some bits are requests to the stack to try to generate timestamps. Any
  61 combination of them is valid. Changes to these bits apply to newly
  62 created packets, not to packets already in the stack. As a result, it
  63 is possible to selectively request timestamps for a subset of packets
  64 (e.g., for sampling) by embedding an send() call within two setsockopt
  65 calls, one to enable timestamp generation and one to disable it.
  66 Timestamps may also be generated for reasons other than being
  67 requested by a particular socket, such as when receive timestamping is
  68 enabled system wide, as explained earlier.
  69
  70 SOF_TIMESTAMPING_RX_HARDWARE:
  71   Request rx timestamps generated by the network adapter.
  72
  73 SOF_TIMESTAMPING_RX_SOFTWARE:
  74   Request rx timestamps when data enters the kernel. These timestamps
  75   are generated just after a device driver hands a packet to the
  76   kernel receive stack.
  77
  78 SOF_TIMESTAMPING_TX_HARDWARE:
  79   Request tx timestamps generated by the network adapter. This flag
  80   can be enabled via both socket options and control messages.
  81
  82 SOF_TIMESTAMPING_TX_SOFTWARE:
  83   Request tx timestamps when data leaves the kernel. These timestamps
  84   are generated in the device driver as close as possible, but always
  85   prior to, passing the packet to the network interface. Hence, they
  86   require driver support and may not be available for all devices.
  87   This flag can be enabled via both socket options and control messages.
  88
  89
  90 SOF_TIMESTAMPING_TX_SCHED:
  91   Request tx timestamps prior to entering the packet scheduler. Kernel
  92   transmit latency is, if long, often dominated by queuing delay. The
  93   difference between this timestamp and one taken at
  94   SOF_TIMESTAMPING_TX_SOFTWARE will expose this latency independent
  95   of protocol processing. The latency incurred in protocol
  96   processing, if any, can be computed by subtracting a userspace
  97   timestamp taken immediately before send() from this timestamp. On
  98   machines with virtual devices where a transmitted packet travels
  99   through multiple devices and, hence, multiple packet schedulers,
 100   a timestamp is generated at each layer. This allows for fine
 101   grained measurement of queuing delay. This flag can be enabled
 102   via both socket options and control messages.
 103
 104 SOF_TIMESTAMPING_TX_ACK:
 105   Request tx timestamps when all data in the send buffer has been
 106   acknowledged. This only makes sense for reliable protocols. It is
 107   currently only implemented for TCP. For that protocol, it may
 108   over-report measurement, because the timestamp is generated when all
 109   data up to and including the buffer at send() was acknowledged: the
 110   cumulative acknowledgment. The mechanism ignores SACK and FACK.
 111   This flag can be enabled via both socket options and control messages.
 112
 113
 114 1.3.2 Timestamp Reporting
 115
 116 The other three bits control which timestamps will be reported in a
 117 generated control message. Changes to the bits take immediate
 118 effect at the timestamp reporting locations in the stack. Timestamps
 119 are only reported for packets that also have the relevant timestamp
 120 generation request set.
 121
 122 SOF_TIMESTAMPING_SOFTWARE:
 123   Report any software timestamps when available.
 124
 125 SOF_TIMESTAMPING_SYS_HARDWARE:
 126   This option is deprecated and ignored.
 127
 128 SOF_TIMESTAMPING_RAW_HARDWARE:
 129   Report hardware timestamps as generated by
 130   SOF_TIMESTAMPING_TX_HARDWARE when available.
 131
 132
 133 1.3.3 Timestamp Options
 134
 135 The interface supports the options
 136
 137 SOF_TIMESTAMPING_OPT_ID:
 138
 139   Generate a unique identifier along with each packet. A process can
 140   have multiple concurrent timestamping requests outstanding. Packets
 141   can be reordered in the transmit path, for instance in the packet
 142   scheduler. In that case timestamps will be queued onto the error
 143   queue out of order from the original send() calls. It is not always
 144   possible to uniquely match timestamps to the original send() calls
 145   based on timestamp order or payload inspection alone, then.
 146
 147   This option associates each packet at send() with a unique
 148   identifier and returns that along with the timestamp. The identifier
 149   is derived from a per-socket u32 counter (that wraps). For datagram
 150   sockets, the counter increments with each sent packet. For stream
 151   sockets, it increments with every byte.
 152
 153   The counter starts at zero. It is initialized the first time that
 154   the socket option is enabled. It is reset each time the option is
 155   enabled after having been disabled. Resetting the counter does not
 156   change the identifiers of existing packets in the system.
 157
 158   This option is implemented only for transmit timestamps. There, the
 159   timestamp is always looped along with a struct sock_extended_err.
 160   The option modifies field ee_data to pass an id that is unique
 161   among all possibly concurrently outstanding timestamp requests for
 162   that socket.
 163
 164
 165 SOF_TIMESTAMPING_OPT_CMSG:
 166
 167   Support recv() cmsg for all timestamped packets. Control messages
 168   are already supported unconditionally on all packets with receive
 169   timestamps and on IPv6 packets with transmit timestamp. This option
 170   extends them to IPv4 packets with transmit timestamp. One use case
 171   is to correlate packets with their egress device, by enabling socket
 172   option IP_PKTINFO simultaneously.
 173
 174
 175 SOF_TIMESTAMPING_OPT_TSONLY:
 176
 177   Applies to transmit timestamps only. Makes the kernel return the
 178   timestamp as a cmsg alongside an empty packet, as opposed to
 179   alongside the original packet. This reduces the amount of memory
 180   charged to the socket's receive budget (SO_RCVBUF) and delivers
 181   the timestamp even if sysctl net.core.tstamp_allow_data is 0.
 182   This option disables SOF_TIMESTAMPING_OPT_CMSG.
 183
 184 SOF_TIMESTAMPING_OPT_STATS:
 185
 186   Optional stats that are obtained along with the transmit timestamps.
 187   It must be used together with SOF_TIMESTAMPING_OPT_TSONLY. When the
 188   transmit timestamp is available, the stats are available in a
 189   separate control message of type SCM_TIMESTAMPING_OPT_STATS, as a
 190   list of TLVs (struct nlattr) of types. These stats allow the
 191   application to associate various transport layer stats with
 192   the transmit timestamps, such as how long a certain block of
 193   data was limited by peer's receiver window.
 194
 195 SOF_TIMESTAMPING_OPT_PKTINFO:
 196
 197   Enable the SCM_TIMESTAMPING_PKTINFO control message for incoming
 198   packets with hardware timestamps. The message contains struct
 199   scm_ts_pktinfo, which supplies the index of the real interface which
 200   received the packet and its length at layer 2. A valid (non-zero)
 201   interface index will be returned only if CONFIG_NET_RX_BUSY_POLL is
 202   enabled and the driver is using NAPI. The struct contains also two
 203   other fields, but they are reserved and undefined.
 204
 205 SOF_TIMESTAMPING_OPT_TX_SWHW:
 206
 207   Request both hardware and software timestamps for outgoing packets
 208   when SOF_TIMESTAMPING_TX_HARDWARE and SOF_TIMESTAMPING_TX_SOFTWARE
 209   are enabled at the same time. If both timestamps are generated,
 210   two separate messages will be looped to the socket's error queue,
 211   each containing just one timestamp.
 212
 213 New applications are encouraged to pass SOF_TIMESTAMPING_OPT_ID to
 214 disambiguate timestamps and SOF_TIMESTAMPING_OPT_TSONLY to operate
 215 regardless of the setting of sysctl net.core.tstamp_allow_data.
 216
 217 An exception is when a process needs additional cmsg data, for
 218 instance SOL_IP/IP_PKTINFO to detect the egress network interface.
 219 Then pass option SOF_TIMESTAMPING_OPT_CMSG. This option depends on
 220 having access to the contents of the original packet, so cannot be
 221 combined with SOF_TIMESTAMPING_OPT_TSONLY.
 222
 223
 224 1.3.4. Enabling timestamps via control messages
 225
 226 In addition to socket options, timestamp generation can be requested
 227 per write via cmsg, only for SOF_TIMESTAMPING_TX_* (see Section 1.3.1).
 228 Using this feature, applications can sample timestamps per sendmsg()
 229 without paying the overhead of enabling and disabling timestamps via
 230 setsockopt:
 231
 232   struct msghdr *msg;
 233   ...
 234   cmsg                         = CMSG_FIRSTHDR(msg);
 235   cmsg->cmsg_level             = SOL_SOCKET;
 236   cmsg->cmsg_type              = SO_TIMESTAMPING;
 237   cmsg->cmsg_len               = CMSG_LEN(sizeof(__u32));
 238   *((__u32 *) CMSG_DATA(cmsg)) = SOF_TIMESTAMPING_TX_SCHED |
 239                                  SOF_TIMESTAMPING_TX_SOFTWARE |
 240                                  SOF_TIMESTAMPING_TX_ACK;
 241   err = sendmsg(fd, msg, 0);
 242
 243 The SOF_TIMESTAMPING_TX_* flags set via cmsg will override
 244 the SOF_TIMESTAMPING_TX_* flags set via setsockopt.
 245
 246 Moreover, applications must still enable timestamp reporting via
 247 setsockopt to receive timestamps:
 248
 249   __u32 val = SOF_TIMESTAMPING_SOFTWARE |
 250               SOF_TIMESTAMPING_OPT_ID /* or any other flag */;
 251   err = setsockopt(fd, SOL_SOCKET, SO_TIMESTAMPING, &val, sizeof(val));
 252
 253
 254 1.4 Bytestream Timestamps
 255
 256 The SO_TIMESTAMPING interface supports timestamping of bytes in a
 257 bytestream. Each request is interpreted as a request for when the
 258 entire contents of the buffer has passed a timestamping point. That
 259 is, for streams option SOF_TIMESTAMPING_TX_SOFTWARE will record
 260 when all bytes have reached the device driver, regardless of how
 261 many packets the data has been converted into.
 262
 263 In general, bytestreams have no natural delimiters and therefore
 264 correlating a timestamp with data is non-trivial. A range of bytes
 265 may be split across segments, any segments may be merged (possibly
 266 coalescing sections of previously segmented buffers associated with
 267 independent send() calls). Segments can be reordered and the same
 268 byte range can coexist in multiple segments for protocols that
 269 implement retransmissions.
 270
 271 It is essential that all timestamps implement the same semantics,
 272 regardless of these possible transformations, as otherwise they are
 273 incomparable. Handling "rare" corner cases differently from the
 274 simple case (a 1:1 mapping from buffer to skb) is insufficient
 275 because performance debugging often needs to focus on such outliers.
 276
 277 In practice, timestamps can be correlated with segments of a
 278 bytestream consistently, if both semantics of the timestamp and the
 279 timing of measurement are chosen correctly. This challenge is no
 280 different from deciding on a strategy for IP fragmentation. There, the
 281 definition is that only the first fragment is timestamped. For
 282 bytestreams, we chose that a timestamp is generated only when all
 283 bytes have passed a point. SOF_TIMESTAMPING_TX_ACK as defined is easy to
 284 implement and reason about. An implementation that has to take into
 285 account SACK would be more complex due to possible transmission holes
 286 and out of order arrival.
 287
 288 On the host, TCP can also break the simple 1:1 mapping from buffer to
 289 skbuff as a result of Nagle, cork, autocork, segmentation and GSO. The
 290 implementation ensures correctness in all cases by tracking the
 291 individual last byte passed to send(), even if it is no longer the
 292 last byte after an skbuff extend or merge operation. It stores the
 293 relevant sequence number in skb_shinfo(skb)->tskey. Because an skbuff
 294 has only one such field, only one timestamp can be generated.
 295
 296 In rare cases, a timestamp request can be missed if two requests are
 297 collapsed onto the same skb. A process can detect this situation by
 298 enabling SOF_TIMESTAMPING_OPT_ID and comparing the byte offset at
 299 send time with the value returned for each timestamp. It can prevent
 300 the situation by always flushing the TCP stack in between requests,
 301 for instance by enabling TCP_NODELAY and disabling TCP_CORK and
 302 autocork.
 303
 304 These precautions ensure that the timestamp is generated only when all
 305 bytes have passed a timestamp point, assuming that the network stack
 306 itself does not reorder the segments. The stack indeed tries to avoid
 307 reordering. The one exception is under administrator control: it is
 308 possible to construct a packet scheduler configuration that delays
 309 segments from the same stream differently. Such a setup would be
 310 unusual.
 311
 312
 313 2 Data Interfaces
 314
 315 Timestamps are read using the ancillary data feature of recvmsg().
 316 See `man 3 cmsg` for details of this interface. The socket manual
 317 page (`man 7 socket`) describes how timestamps generated with
 318 SO_TIMESTAMP and SO_TIMESTAMPNS records can be retrieved.
 319
 320
 321 2.1 SCM_TIMESTAMPING records
 322
 323 These timestamps are returned in a control message with cmsg_level
 324 SOL_SOCKET, cmsg_type SCM_TIMESTAMPING, and payload of type
 325
 326 struct scm_timestamping {
 327         struct timespec ts[3];
 328 };
 329
 330 The structure can return up to three timestamps. This is a legacy
 331 feature. At least one field is non-zero at any time. Most timestamps
 332 are passed in ts[0]. Hardware timestamps are passed in ts[2].
 333
 334 ts[1] used to hold hardware timestamps converted to system time.
 335 Instead, expose the hardware clock device on the NIC directly as
 336 a HW PTP clock source, to allow time conversion in userspace and
 337 optionally synchronize system time with a userspace PTP stack such
 338 as linuxptp. For the PTP clock API, see Documentation/ptp/ptp.txt.
 339
 340 Note that if the SO_TIMESTAMP or SO_TIMESTAMPNS option is enabled
 341 together with SO_TIMESTAMPING using SOF_TIMESTAMPING_SOFTWARE, a false
 342 software timestamp will be generated in the recvmsg() call and passed
 343 in ts[0] when a real software timestamp is missing. This happens also
 344 on hardware transmit timestamps.
 345
 346 2.1.1 Transmit timestamps with MSG_ERRQUEUE
 347
 348 For transmit timestamps the outgoing packet is looped back to the
 349 socket's error queue with the send timestamp(s) attached. A process
 350 receives the timestamps by calling recvmsg() with flag MSG_ERRQUEUE
 351 set and with a msg_control buffer sufficiently large to receive the
 352 relevant metadata structures. The recvmsg call returns the original
 353 outgoing data packet with two ancillary messages attached.
 354
 355 A message of cm_level SOL_IP(V6) and cm_type IP(V6)_RECVERR
 356 embeds a struct sock_extended_err. This defines the error type. For
 357 timestamps, the ee_errno field is ENOMSG. The other ancillary message
 358 will have cm_level SOL_SOCKET and cm_type SCM_TIMESTAMPING. This
 359 embeds the struct scm_timestamping.
 360
 361
 362 2.1.1.2 Timestamp types
 363
 364 The semantics of the three struct timespec are defined by field
 365 ee_info in the extended error structure. It contains a value of
 366 type SCM_TSTAMP_* to define the actual timestamp passed in
 367 scm_timestamping.
 368
 369 The SCM_TSTAMP_* types are 1:1 matches to the SOF_TIMESTAMPING_*
 370 control fields discussed previously, with one exception. For legacy
 371 reasons, SCM_TSTAMP_SND is equal to zero and can be set for both
 372 SOF_TIMESTAMPING_TX_HARDWARE and SOF_TIMESTAMPING_TX_SOFTWARE. It
 373 is the first if ts[2] is non-zero, the second otherwise, in which
 374 case the timestamp is stored in ts[0].
 375
 376
 377 2.1.1.3 Fragmentation
 378
 379 Fragmentation of outgoing datagrams is rare, but is possible, e.g., by
 380 explicitly disabling PMTU discovery. If an outgoing packet is fragmented,
 381 then only the first fragment is timestamped and returned to the sending
 382 socket.
 383
 384
 385 2.1.1.4 Packet Payload
 386
 387 The calling application is often not interested in receiving the whole
 388 packet payload that it passed to the stack originally: the socket
 389 error queue mechanism is just a method to piggyback the timestamp on.
 390 In this case, the application can choose to read datagrams with a
 391 smaller buffer, possibly even of length 0. The payload is truncated
 392 accordingly. Until the process calls recvmsg() on the error queue,
 393 however, the full packet is queued, taking up budget from SO_RCVBUF.
 394
 395
 396 2.1.1.5 Blocking Read
 397
 398 Reading from the error queue is always a non-blocking operation. To
 399 block waiting on a timestamp, use poll or select. poll() will return
 400 POLLERR in pollfd.revents if any data is ready on the error queue.
 401 There is no need to pass this flag in pollfd.events. This flag is
 402 ignored on request. See also `man 2 poll`.
 403
 404
 405 2.1.2 Receive timestamps
 406
 407 On reception, there is no reason to read from the socket error queue.
 408 The SCM_TIMESTAMPING ancillary data is sent along with the packet data
 409 on a normal recvmsg(). Since this is not a socket error, it is not
 410 accompanied by a message SOL_IP(V6)/IP(V6)_RECVERROR. In this case,
 411 the meaning of the three fields in struct scm_timestamping is
 412 implicitly defined. ts[0] holds a software timestamp if set, ts[1]
 413 is again deprecated and ts[2] holds a hardware timestamp if set.
 414
 415
 416 3. Hardware Timestamping configuration: SIOCSHWTSTAMP and SIOCGHWTSTAMP
 417
 418 Hardware time stamping must also be initialized for each device driver
 419 that is expected to do hardware time stamping. The parameter is defined in
 420 include/uapi/linux/net_tstamp.h as:
 421
 422 struct hwtstamp_config {
 423         int flags;      /* no flags defined right now, must be zero */
 424         int tx_type;    /* HWTSTAMP_TX_* */
 425         int rx_filter;  /* HWTSTAMP_FILTER_* */
 426 };
 427
 428 Desired behavior is passed into the kernel and to a specific device by
 429 calling ioctl(SIOCSHWTSTAMP) with a pointer to a struct ifreq whose
 430 ifr_data points to a struct hwtstamp_config. The tx_type and
 431 rx_filter are hints to the driver what it is expected to do. If
 432 the requested fine-grained filtering for incoming packets is not
 433 supported, the driver may time stamp more than just the requested types
 434 of packets.
 435
 436 Drivers are free to use a more permissive configuration than the requested
 437 configuration. It is expected that drivers should only implement directly the
 438 most generic mode that can be supported. For example if the hardware can
 439 support HWTSTAMP_FILTER_V2_EVENT, then it should generally always upscale
 440 HWTSTAMP_FILTER_V2_L2_SYNC_MESSAGE, and so forth, as HWTSTAMP_FILTER_V2_EVENT
 441 is more generic (and more useful to applications).
 442
 443 A driver which supports hardware time stamping shall update the struct
 444 with the actual, possibly more permissive configuration. If the
 445 requested packets cannot be time stamped, then nothing should be
 446 changed and ERANGE shall be returned (in contrast to EINVAL, which
 447 indicates that SIOCSHWTSTAMP is not supported at all).
 448
 449 Only a processes with admin rights may change the configuration. User
 450 space is responsible to ensure that multiple processes don't interfere
 451 with each other and that the settings are reset.
 452
 453 Any process can read the actual configuration by passing this
 454 structure to ioctl(SIOCGHWTSTAMP) in the same way.  However, this has
 455 not been implemented in all drivers.
 456
 457 /* possible values for hwtstamp_config->tx_type */
 458 enum {
 459         /*
 460          * no outgoing packet will need hardware time stamping;
 461          * should a packet arrive which asks for it, no hardware
 462          * time stamping will be done
 463          */
 464         HWTSTAMP_TX_OFF,
 465
 466         /*
 467          * enables hardware time stamping for outgoing packets;
 468          * the sender of the packet decides which are to be
 469          * time stamped by setting SOF_TIMESTAMPING_TX_SOFTWARE
 470          * before sending the packet
 471          */
 472         HWTSTAMP_TX_ON,
 473 };
 474
 475 /* possible values for hwtstamp_config->rx_filter */
 476 enum {
 477         /* time stamp no incoming packet at all */
 478         HWTSTAMP_FILTER_NONE,
 479
 480         /* time stamp any incoming packet */
 481         HWTSTAMP_FILTER_ALL,
 482
 483         /* return value: time stamp all packets requested plus some others */
 484         HWTSTAMP_FILTER_SOME,
 485
 486         /* PTP v1, UDP, any kind of event packet */
 487         HWTSTAMP_FILTER_PTP_V1_L4_EVENT,
 488
 489         /* for the complete list of values, please check
 490          * the include file include/uapi/linux/net_tstamp.h
 491          */
 492 };
 493
 494 3.1 Hardware Timestamping Implementation: Device Drivers
 495
 496 A driver which supports hardware time stamping must support the
 497 SIOCSHWTSTAMP ioctl and update the supplied struct hwtstamp_config with
 498 the actual values as described in the section on SIOCSHWTSTAMP.  It
 499 should also support SIOCGHWTSTAMP.
 500
 501 Time stamps for received packets must be stored in the skb. To get a pointer
 502 to the shared time stamp structure of the skb call skb_hwtstamps(). Then
 503 set the time stamps in the structure:
 504
 505 struct skb_shared_hwtstamps {
 506         /* hardware time stamp transformed into duration
 507          * since arbitrary point in time
 508          */
 509         ktime_t hwtstamp;
 510 };
 511
 512 Time stamps for outgoing packets are to be generated as follows:
 513 - In hard_start_xmit(), check if (skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP)
 514   is set no-zero. If yes, then the driver is expected to do hardware time
 515   stamping.
 516 - If this is possible for the skb and requested, then declare
 517   that the driver is doing the time stamping by setting the flag
 518   SKBTX_IN_PROGRESS in skb_shinfo(skb)->tx_flags , e.g. with
 519
 520       skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS;
 521
 522   You might want to keep a pointer to the associated skb for the next step
 523   and not free the skb. A driver not supporting hardware time stamping doesn't
 524   do that. A driver must never touch sk_buff::tstamp! It is used to store
 525   software generated time stamps by the network subsystem.
 526 - Driver should call skb_tx_timestamp() as close to passing sk_buff to hardware
 527   as possible. skb_tx_timestamp() provides a software time stamp if requested
 528   and hardware timestamping is not possible (SKBTX_IN_PROGRESS not set).
 529 - As soon as the driver has sent the packet and/or obtained a
 530   hardware time stamp for it, it passes the time stamp back by
 531   calling skb_hwtstamp_tx() with the original skb, the raw
 532   hardware time stamp. skb_hwtstamp_tx() clones the original skb and
 533   adds the timestamps, therefore the original skb has to be freed now.
 534   If obtaining the hardware time stamp somehow fails, then the driver
 535   should not fall back to software time stamping. The rationale is that
 536   this would occur at a later time in the processing pipeline than other
 537   software time stamping and therefore could lead to unexpected deltas
 538   between time stamps.