Potential RTE bitset RFC

Potential RTE bitset RFC

[Mattias Rönnblom]

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.

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.

Regards,
	Mattias

RE: Potential RTE bitset RFC

[Morten Brørup]

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

-Morten

Re: Potential RTE bitset RFC

[fengchengwen]

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
> 

Re: 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@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.

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

Re: Potential RTE bitset RFC

[Mattias Rönnblom]

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.

RE: Potential RTE bitset RFC

[Morten Brørup]

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

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!