timestamp resolution

[Morten Brørup]

> From: Robin Jarry [mailto:rjarry at redhat.com]
> Sent: Thursday, 21 May 2026 12.55

[...]

> Did you find any hotspots while profiling regarding timestamps?

Now that you are asking...
Algorithm level optimization beats micro-optimization.

Reading the clock is quite expensive.
Our applications use an optimization where the clock is only read once when entering certain stages.
It is then converted to various formats, which are stored locally for fast access.
When processing packets in a burst, the same cached value is used for all those packets.
The cached values are often reusable for multiple stages of the packet processing pipeline, but I don't know if that could fit into the graph design.

In a previous version of the optimization, we cached the packet's ingress timestamp in the mbuf structure, and used that timestamp in the packet processing stages up until the packet was put in a shaper queue.


Also, as a micro-optimization, rte_rdtsc() is accurate enough for most purposes, so clock_gettime() can be avoided in those cases.