Potential RTE bitset RFC

[Mattias Rönnblom]

On 2024-01-29 04:02, fengchengwen wrote:
> Hi,
> 
> On 2024/1/28 21: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.
> 
> 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.

RTE bitmap is for large bitsets. This library is for small bitsets where 
performance is crucial (i.e., you can't live with the "extra" spacial 
and/or temporal overhead of rte_bitmap.h).

Stephen Hemminger suggested supporting atomic operations in this API. 
The would make sense to me as well.

void
rte_bitset_atomic_set(uint64_t *bitset, size_t bit_num, int memory_model);

or, alternatively, you only provided a get/set with a relaxed memory 
model, and you could loose the memory model parameter.

> 
>>
>>>
>>> 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
>>