> From: Mattias Rönnblom [mailto:hof...@lysator.liu.se] > Sent: Monday, 29 January 2024 07.52 > > 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.
We have other categories of libraries with separate APIs for variants, e.g. rte_hash and rte_fbk_hash. So we could also have two APIs for different timer library variants, although I might be alone in the DPDK community with this opinion regarding timer libraries. From a high level perspective, I agree that a more unified API is preferable. If you consider a long term road map leading to a unified API more of a "must have" than a "nice to have", it makes really good sense to think that through before contributing new components, and I will not press for a core HTW library. PS: If DPDK was written in C++, I would generally press for common superclass templates and be opposed to multiple standalone libraries with similar properties. But it's not. And sometimes purpose-specific variants of otherwise similar libraries do make sense, especially in the fast path, where every cycle is precious!
