On 2023-07-07 00:41, Stephen Hemminger wrote: > 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. > > 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.
