Potential RTE bitset RFC

[Morten Brørup]

> From: Mattias Rönnblom [mailto:hofors at 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:hofors at 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 at 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!