Re: Potential RTE bitset RFC

[fengchengwen <fengchengwen@huawei.com>]

Hi,

On 2024/1/28 21: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.

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.

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