Doug / smarc-fsl-linux-kernel

Download as
Browse Code ยป

Commit 2940b26bec9fe5bf183c994678e62b55d35717e6

Authored by Daniel Borkmann
Committed by David S. Miller
1 parent b9c32fb271
Exists in smarc-l5.0.0_1.0.0-ga and in 5 other branches imx_3.10.17_1.0.1_ga, imx_3.10.53_1.1.0_ga, imx_3.14.28_1.0.0_ga, smarc-imx_3.10.53_1.1.0_ga, smarc-imx_3.14.28_1.0.0_ga

packet: doc: update timestamping part 

Bring the timestamping section in sync with the implementation.

Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Acked-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Showing 1 changed file with 35 additions and 6 deletions Side-by-side Diff

Documentation/networking/packet_mmap.txt
Diff comments   View file @ 2940b26
... ... @@ -1016,10 +1016,11 @@
1016 1016 -------------------------------------------------------------------------------
1017 1017  
1018 1018 The PACKET_TIMESTAMP setting determines the source of the timestamp in
1019   -the packet meta information. If your NIC is capable of timestamping
1020   -packets in hardware, you can request those hardware timestamps to used.
1021   -Note: you may need to enable the generation of hardware timestamps with
1022   -SIOCSHWTSTAMP.
  1019 +the packet meta information for mmap(2)ed RX_RING and TX_RINGs. If your
  1020 +NIC is capable of timestamping packets in hardware, you can request those
  1021 +hardware timestamps to be used. Note: you may need to enable the generation
  1022 +of hardware timestamps with SIOCSHWTSTAMP (see related information from
  1023 +Documentation/networking/timestamping.txt).
1023 1024  
1024 1025 PACKET_TIMESTAMP accepts the same integer bit field as
1025 1026 SO_TIMESTAMPING. However, only the SOF_TIMESTAMPING_SYS_HARDWARE
... ... @@ -1031,8 +1032,36 @@
1031 1032 req |= SOF_TIMESTAMPING_SYS_HARDWARE;
1032 1033 setsockopt(fd, SOL_PACKET, PACKET_TIMESTAMP, (void *) &req, sizeof(req))
1033 1034  
1034   -If PACKET_TIMESTAMP is not set, a software timestamp generated inside
1035   -the networking stack is used (the behavior before this setting was added).
  1035 +For the mmap(2)ed ring buffers, such timestamps are stored in the
  1036 +tpacket{,2,3}_hdr structure's tp_sec and tp_{n,u}sec members. To determine
  1037 +what kind of timestamp has been reported, the tp_status field is binary |'ed
  1038 +with the following possible bits ...
  1039 +
  1040 + TP_STATUS_TS_SYS_HARDWARE
  1041 + TP_STATUS_TS_RAW_HARDWARE
  1042 + TP_STATUS_TS_SOFTWARE
  1043 +
  1044 +... that are equivalent to its SOF_TIMESTAMPING_* counterparts. For the
  1045 +RX_RING, if none of those 3 are set (i.e. PACKET_TIMESTAMP is not set),
  1046 +then this means that a software fallback was invoked *within* PF_PACKET's
  1047 +processing code (less precise).
  1048 +
  1049 +Getting timestamps for the TX_RING works as follows: i) fill the ring frames,
  1050 +ii) call sendto() e.g. in blocking mode, iii) wait for status of relevant
  1051 +frames to be updated resp. the frame handed over to the application, iv) walk
  1052 +through the frames to pick up the individual hw/sw timestamps.
  1053 +
  1054 +Only (!) if transmit timestamping is enabled, then these bits are combined
  1055 +with binary | with TP_STATUS_AVAILABLE, so you must check for that in your
  1056 +application (e.g. !(tp_status & (TP_STATUS_SEND_REQUEST | TP_STATUS_SENDING))
  1057 +in a first step to see if the frame belongs to the application, and then
  1058 +one can extract the type of timestamp in a second step from tp_status)!
  1059 +
  1060 +If you don't care about them, thus having it disabled, checking for
  1061 +TP_STATUS_AVAILABLE resp. TP_STATUS_WRONG_FORMAT is sufficient. If in the
  1062 +TX_RING part only TP_STATUS_AVAILABLE is set, then the tp_sec and tp_{n,u}sec
  1063 +members do not contain a valid value. For TX_RINGs, by default no timestamp
  1064 +is generated!
1036 1065  
1037 1066 See include/linux/net_tstamp.h and Documentation/networking/timestamping
1038 1067 for more information on hardware timestamps.