On Wed, 15 Mar 2023 18:03:42 +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 hierarchical timer wheels and a
> message-based synchronization/MT-safety scheme.
>
> RFC v2:
> * Fix spelling.
> * Fix signed/unsigned comparisons and discontinue the use of name-less
> function parameters, both of which may result in compiler warnings.
> * Undo the accidental removal of the bitset tests from the 'fast_tests'.
> * Add a number of missing include files, causing build failures
> (e.g., on AArch64 builds).
> * Add perf test attempting to compare rte_timer, rte_htimer and rte_htw.
> * Use nanoseconds (instead of TSC) as the default time unit.
> * add() and manage() has flags which allows the caller to specify the
> time unit (nanoseconds, TSC, or ticks) for the times provided.
>
> Signed-off-by: Mattias Rönnblom <mattias.ronnb...@ericsson.com>
Initial reactions.
Good:
- timer API does need work
- the units and API's model seems good, would have to look at real
applications
- tests look good as well.
Bad:
- why do we need a new timer infrastructure. Could this not be done
by extending and embracing the existing rte_timer() API's.
- having fast rte_timer() would make existing app's faster.
PS:
- ok to drop all the rte_alt_timer stuff, don't think any application depends
on it.
my survey of github projects, only one usage (OpenDataplane).
-
