On 2024-01-28 14:52, Morten Brørup wrote:
From: Mattias Rönnblom [mailto:hof...@lysator.liu.se]
Sent: Saturday, 27 January 2024 19.32
Hi.
The new timer RFC ("htimer") I submitted last year also included a new
bitset API.
https://patchwork.dpdk.org/project/dpdk/patch/20230315170342.214127-2-
mattias.ronnb...@ericsson.com/
My experience is that multi-word bitsets are often useful. Examples
from
DPDK are rte_service.c and DSW its "service ports" bitset (both have 64
as a hard upper limit). Small, but multi-word, bitsets are not
particularly hard to open-code, but then you end up with a lot of
duplication.
I wanted to ask if there is an interest in seeing a bitset API (as per
my patchset) in DPDK.
Absolutely!
Your bitset patch seems very complete, with test cases and all.
Let's standardize on this, so we can avoid variants of similar code all over
the place.
Upstreaming htimer, including having it replace today's rte_timer is
more work than I can commit to, so I think you won't get RTE bitset
that
way any time soon.
Thanks for the update regarding the htimer progress. :-)
I certainly don't object to a dedicated fast path library for high-volume
timers, such as those in a TCP/IP (or QUIC/IP) stack.
In my opinion, the existing rte_timer library can be improved at a later stage,
if anybody cares. It's a shame if that requirement is holding back the addition
of a new and useful library.
You could just add the core HTW parts of the htimer library to DPDK as a
new library (and leave out the rest of htimer), but in that case you
want to tailor this API to fit a future HTW-based rte_timer
implementation. Without actually implementing such a replacement, it's
hard to know exactly what properties you want from the HTW
API/implementation.
Therefor, I think you should do both at the same time.
