Re: dumpcap: timestamp is years ahead when in pcapng format

[Isaac Boukris <iboukris@gmail.com>]

Looking with git log, i found the original line was:
return pcapng_time.ns + (delta * NSEC_PER_SEC) / rte_get_tsc_hz();

Testing that does show a wrapping issue, e.g. (it stays around 08:05).

2023-09-19 08:05:24.372037 IP _gateway.domain > Rocky8.38358: 31975
NXDomain 0/0/0 (46)                                              10
2023-09-19 08:05:21.577497 ARP, Request who-has _gateway tell Rocky8,
length 46
2023-09-19 08:05:21.577599 ARP, Reply _gateway is-at 00:50:56:f8:92:76
(oui Unknown), length 46                                     13
2023-09-19 08:05:22.833897 IP 192.168.202.1.50886 >
239.255.255.250.ssdp: UDP, length 174

However with my change it looks fine and always increments. I dropped
all the parenthesis:
return pcapng_time.ns + delta / pcapng_time.tsc_hz * NSEC_PER_SEC;

On Tue, Sep 19, 2023 at 5:40 PM Isaac Boukris <iboukris@gmail.com> wrote:
>
> 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@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@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!