Re: [RFC 2/2] eal: add high-performance timer facility

["Mattias Rönnblom" <hofors@lysator.liu.se>]

On 2023-03-05 18:25, Stephen Hemminger wrote:
> On Tue, 28 Feb 2023 10:39:16 +0100
> Mattias Rönnblom <mattias.ronnblom@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.ronnblom@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?