diff options
author | Daniel Borkmann <dborkman@redhat.com> | 2013-04-22 20:39:32 -0400 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2013-04-25 01:22:22 -0400 |
commit | 2940b26bec9fe5bf183c994678e62b55d35717e6 (patch) | |
tree | 2413117b5a07e3632a392e4f03a76ebb37e9c157 /Documentation | |
parent | b9c32fb2717094231b31a7d7dcf5fd7f3638ac2f (diff) |
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>
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/networking/packet_mmap.txt | 41 |
1 files changed, 35 insertions, 6 deletions
diff --git a/Documentation/networking/packet_mmap.txt b/Documentation/networking/packet_mmap.txt index 65efb85e49de..23dd80e82b8e 100644 --- a/Documentation/networking/packet_mmap.txt +++ b/Documentation/networking/packet_mmap.txt | |||
@@ -1016,10 +1016,11 @@ retry_block: | |||
1016 | ------------------------------------------------------------------------------- | 1016 | ------------------------------------------------------------------------------- |
1017 | 1017 | ||
1018 | The PACKET_TIMESTAMP setting determines the source of the timestamp in | 1018 | The PACKET_TIMESTAMP setting determines the source of the timestamp in |
1019 | the packet meta information. If your NIC is capable of timestamping | 1019 | the packet meta information for mmap(2)ed RX_RING and TX_RINGs. If your |
1020 | packets in hardware, you can request those hardware timestamps to used. | 1020 | NIC is capable of timestamping packets in hardware, you can request those |
1021 | Note: you may need to enable the generation of hardware timestamps with | 1021 | hardware timestamps to be used. Note: you may need to enable the generation |
1022 | SIOCSHWTSTAMP. | 1022 | of hardware timestamps with SIOCSHWTSTAMP (see related information from |
1023 | Documentation/networking/timestamping.txt). | ||
1023 | 1024 | ||
1024 | PACKET_TIMESTAMP accepts the same integer bit field as | 1025 | PACKET_TIMESTAMP accepts the same integer bit field as |
1025 | SO_TIMESTAMPING. However, only the SOF_TIMESTAMPING_SYS_HARDWARE | 1026 | SO_TIMESTAMPING. However, only the SOF_TIMESTAMPING_SYS_HARDWARE |
@@ -1031,8 +1032,36 @@ SOF_TIMESTAMPING_RAW_HARDWARE if both bits are set. | |||
1031 | req |= SOF_TIMESTAMPING_SYS_HARDWARE; | 1032 | req |= SOF_TIMESTAMPING_SYS_HARDWARE; |
1032 | setsockopt(fd, SOL_PACKET, PACKET_TIMESTAMP, (void *) &req, sizeof(req)) | 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 | For the mmap(2)ed ring buffers, such timestamps are stored in the |
1035 | the networking stack is used (the behavior before this setting was added). | 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 | See include/linux/net_tstamp.h and Documentation/networking/timestamping | 1066 | See include/linux/net_tstamp.h and Documentation/networking/timestamping |
1038 | for more information on hardware timestamps. | 1067 | for more information on hardware timestamps. |