Hi, On 2024/1/28 21: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.
The bitmap (lib/eal/include/rte_bitmap.h) provides a subset of this bitset library. Maybe it's better to extend the bitmap library. Thanks. > >> >> 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 >
