On 2023-03-05 18:25, Stephen Hemminger wrote:
On Tue, 28 Feb 2023 10:39:16 +0100
Mattias Rönnblom <mattias.ronnb...@ericsson.com> wrote:
The htimer library attempts at providing a timer facility with roughly
the same functionality, but less overhead and better scalability than
DPDK timer library.
The htimer library employs per-lcore hierachical timer wheels and a
message-based synchronization/MT-safety scheme.
Signed-off-by: Mattias Rönnblom <mattias.ronnb...@ericsson.com>
I like this but:
- need to have one timer infrastructure, having multiple will lead to
confusion
and overlap in user applications. I.e can they be mixed, what happens if X
and Y...
- best to keep original API available.
My thoughts on this is that we first converge on the proper future API,
and then you see how close it is to <rte_timer.h>, and if a shim layer
or something of that sort is feasible.
- ok to drop the rte_alt_timer since it was always experimental.
- would be good to have API using consistent known time (nanoseconds?) rather
than TSC cycles.
I will update the RFC to use nanoseconds, at least as the default time unit.
- there could be use cases for REALTIME as well as MONOTONIC types.
The current HTW implementation requires monotonic time (i.e., time can't
go backwards). Realtime clocks typically aren't monotonically increasing.
A naive implementation of backward time travel would be to just
rescheduled all timers.
Would you use one HTW instance per clock?
This makes me think you want a small <rte_time.h> (!= <rte_timer.h>)
time source API as well. It would, among other things, define the clock
ids to use in the rte_htimer_mgr_add() calls. It would also be a good
place in case you want to cache the result of rdtsc instructions (to
have a more course-grained, but more efficient, clock source).
Maybe rte_get_timer_cycles()/hz() (as opposed to rte_get_tsc_cycles())
is a minimalistic attempt in this direction already?
