On 2024-10-03 23:32, Morten Brørup wrote:
From: Stephen Hemminger [mailto:step...@networkplumber.org]
Sent: Thursday, 3 October 2024 20.37
On Wed, 15 Mar 2023 18:03:40 +0100
Mattias Rönnblom <mattias.ronnb...@ericsson.com> wrote:
This patchset is an attempt to introduce a high-performance, highly
scalable timer facility into DPDK.
More specifically, the goals for the htimer library are:
* Efficient handling of a handful up to hundreds of thousands of
concurrent timers.
* Make adding and canceling timers low-overhead, constant-time
operations.
* Provide a service functionally equivalent to that of
<rte_timer.h>. API/ABI backward compatibility is secondary.
Worthwhile goals, and the problem needs to be addressed.
But this patch never got accepted.
I think work on it was put on hold due to the requested changes requiring a
significant development effort.
I too look forward to work on this being resumed. ;-)
Please fix/improve/extend existing rte_timer instead.
The rte_timer API is too "fat" for use in the fast path with millions of
timers, e.g. TCP flow timers.
Shoehorning a fast path feature into a slow path API is not going to cut it. I
support having a separate htimer library with its own API for high volume,
high-performance fast path timers.
When striving for low latency across the internet, timing is everything. Packet pacing is
the "new" hot thing in congestion control algorithms, and a simple software
implementation would require a timer firing once per packet.
I think DPDK should have two public APIs in the timer area. One is a
just a bare-bones hierarchical timer wheel API, without callbacks,
auto-created per-lcore instances, MT safety or any other of the
<rte_timer.h> bells and whistles. It also doesn't make any assumptions
about the time source (other it being monotonic) or resolution.
The other is a new variant of <rte_timer.h>, using the core HTW library
for its implementation (and being public, it may also expose this
library in its header files, which may be required for efficient
operation). The new <rte_timer.h> would provide the same kind of
functionality as the old API, but with some quirks and bugs fixed, plus
potentially some new functionality added. For example, it would be
useful to allow non-preemption safe threads to add and remove timers
(something rte_timer and its spinlocks doesn't allow).
I would consider both "fast path APIs".
In addition, there should probably also be a time source API.
Considering the lead time of relatively small contributions like the
bitops extensions and the new bitset API (which still aren't in), I
can't imagine how long time it would take to get in a semi-backward
compatible rte_timer with a new implementation, plus a new timer wheel
library, into DPDK.
