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

["Mattias Rönnblom" <mattias.ronnblom@ericsson.com>]

On 2023-07-07 00:41, Stephen Hemminger wrote:
> On Wed, 15 Mar 2023 18:03:42 +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.
> 
> I don't understand. Why not just fix and extend existing timers.
> Sure you will need to add some API's and maybe drop some of the existing
> experimental ones (ie alt_timer). Even change the ABI.
> 
> It would be better to have one high performance, scaleable timer than
> spend the next 3 years telling users which one to use and why!
> 
> So please make rte_timer work better in 23.11 release rather
> than reinventing a new variant.

I wanted to explore how a data plane timer API should look like. 
Something like a "first principles" type approach. As it happens, it 
seems like I will converge on something that's pretty similar to how 
rte_timer (and most kernel timers) API works, for example in regards to 
timer memory allocation.

Clearly, there should not be two DPDK timer APIs that provide the same 
functionality. That was never the intention. Since so much DPDK code and 
more importantly application code depends on <rte_timer.h> it wasn't 
obvious that the best option was make extensive changes to rte_timer API 
and implementation. One way that seemed like a plausible option (how 
much so depending on the extend of the rte_timer vs rte_htimer API 
differences) was to have a new API, and depreciate <rte_timer.h> in the 
release htimer was introduced.

That said, at this point, it's not clear to me which option is the best 
one of "making extensive changes to rte_timer" or "having rte_htimer on 
the side for a couple of releases".

An imaginary alternative where the <rte_timer.h> API/ABI can be 
maintained, and you get all the performance and scalability and improved 
API semantics of htimer, would obviously be the best option. But I don't 
think that is possible. Especially not if you want to end up with a 
nice, orthogonal API and a clean implementation.

I think changes in both ABI and API are inevitable, and a good thing, 
considering some of the quirks for the current API.

A side note: It seems to me at this point there should be two public 
timer APIs, but providing different functionality, at slightly different 
levels of abstraction. One is the <rte_timer.h> lookalike, and the other 
what in the current patchset is represented by <rte_htw.h>, but minus 
the callbacks, as per Morten Brørup's suggestion. The latter would be a 
low-level HTW only, with no MT safety, no lcore knowledge, no opinions 
on time source, etc.