dumpcap: timestamp is years ahead when in pcapng format
Isaac Boukris
iboukris at gmail.com
Tue Sep 19 16:40:02 CEST 2023
Hi Stephen,
Machine: vm on a laptop with i7 core
rte_get_timer_hz() = 2500000000
rte_get_tsc_hz() = 2500000000
This issue doesn't occur with pcap format, only with pcapng.
When I capture on my system with dumpcap I get timestamp years ahead:
[root at Rocky8 ~]# dpdk-dumpcap -i 0 -f 'not tcp port 22' -w - | tcpdump -ttttr -
File: -
reading from file -, link-type EN10MB (Ethernet)
Packets captured: 0 dropped privs to tcpdump
2257-07-15 19:27:35.541912 IP _gateway.domain > Rocky8.36824: 42742
NXDomain 0/0/0 (44)
2257-07-15 19:27:35.541912 IP Rocky8.58223 > _gateway.domain: 22616+
PTR? 2.202.168.192.in-addr.arpa. (44)
Looking at the code, I tried the below simplification in
pcapng_tsc_to_ns() and it yielded good results, but I'm still not
clear as the logic is quite intimidating.
diff --git a/lib/pcapng/rte_pcapng.c b/lib/pcapng/rte_pcapng.c
index 80d08e1..96540b4 100644
--- a/lib/pcapng/rte_pcapng.c
+++ b/lib/pcapng/rte_pcapng.c
@@ -79,21 +79,8 @@ static uint64_t pcapng_tsc_to_ns(uint64_t cycles)
* Currently all TSCs operate below 5GHz.
*/
delta = cycles - pcapng_time.cycles;
- if (unlikely(delta >= pcapng_time.tsc_hz)) {
- if (likely(delta < pcapng_time.tsc_hz * 2)) {
- delta -= pcapng_time.tsc_hz;
- pcapng_time.cycles += pcapng_time.tsc_hz;
- pcapng_time.ns += NSEC_PER_SEC;
- } else {
- secs = rte_reciprocal_divide_u64(delta,
&pcapng_time.tsc_hz_inverse);
- delta -= secs * pcapng_time.tsc_hz;
- pcapng_time.cycles += secs * pcapng_time.tsc_hz;
- pcapng_time.ns += secs * NSEC_PER_SEC;
- }
- }
- return pcapng_time.ns + rte_reciprocal_divide_u64(delta * NSEC_PER_SEC,
-
&pcapng_time.tsc_hz_inverse);
+ return pcapng_time.ns + ((uint64_t)(delta /
pcapng_time.tsc_hz) * NSEC_PER_SEC);
Results:
[root at Rocky8 ~]# dpdk-dumpcap -i 0 -f 'not tcp port 22' -w - | tcpdump -ttttr -
File: -
reading from file -, link-type EN10MB (Ethernet)
Packets captured: 0 dropped privs to tcpdump
2023-09-19 05:33:18.191601 IP _gateway.domain > Rocky8.50821: 37740
NXDomain 0/0/0 (44)
2023-09-19 05:33:18.191601 IP Rocky8.57382 > _gateway.domain: 53422+
PTR? 2.202.168.192.in-addr.arpa. (44)
Any thoughts on this?
Thanks!
More information about the users
mailing list