Currently, there is no way to find out which timestamp is reported in tpacket{,2,3}_hdr's tp_sec, tp_{n,u}sec members. It can be one of SOF_TIMESTAMPING_SYS_HARDWARE, SOF_TIMESTAMPING_RAW_HARDWARE, SOF_TIMESTAMPING_SOFTWARE, or a fallback variant late call from the PF_PACKET code in software. Therefore, report in the tp_status member of the ring buffer which timestamp has been reported for RX and TX path. This should not break anything for the following reasons: i) in RX ring path, the user needs to test for tp_status & TP_STATUS_USER, and later for other flags as well such as TP_STATUS_VLAN_VALID et al, so adding other flags will do no harm; ii) in TX ring path, time stamps with PACKET_TIMESTAMP socketoption are not available resp. had no effect except that the application setting this is buggy. Next to TP_STATUS_AVAILABLE, the user also should check for other flags such as TP_STATUS_WRONG_FORMAT to reclaim frames to the application. Thus, in case TX ts are turned off (default case), nothing happens to the application logic, and in case we want to use this new feature, we now can also check which of the ts source is reported in the status field as provided in the docs.
Showing the changes to include/uapi/linux (1 of 2 files). Show all
Unified · Split
| @@ -100,6 +100,11 @@ struct tpacket_auxdata { · 99 unmodified lines | ||
| 100 | 100 | #define TP_STATUS_SENDING (1 << 1) |
| 101 | 101 | #define TP_STATUS_WRONG_FORMAT (1 << 2) |
| 102 | 102 | |
| 103 | +/* Rx and Tx ring - header status */ | |
| 104 | +#define TP_STATUS_TS_SOFTWARE (1 << 29) | |
| 105 | +#define TP_STATUS_TS_SYS_HARDWARE (1 << 30) | |
| 106 | +#define TP_STATUS_TS_RAW_HARDWARE (1 << 31) | |
| 107 | + | |
| 103 | 108 | /* Rx ring - feature request bits */ |
| 104 | 109 | #define TP_FT_REQ_FILL_RXHASH 0x1 |
| 105 | 110 | |