> 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. -Morten
