RE: Potential RTE bitset RFC

["Morten Brørup" <mb@smartsharesystems.com>]

> From: Mattias Rönnblom [mailto:hofors@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.ronnblom@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