Re: Potential RTE bitset RFC

["Mattias Rönnblom" <hofors@lysator.liu.se>]

On 2024-01-28 14:52, Morten Brørup wrote:
>> 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.
> 

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.