DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Mattias Rönnblom" <hofors@lysator.liu.se>
To: "Morten Brørup" <mb@smartsharesystems.com>, dev@dpdk.org
Cc: "Mattias Rönnblom" <mattias.ronnblom@ericsson.com>, techboard@dpdk.org
Subject: Re: Potential RTE bitset RFC
Date: Mon, 29 Jan 2024 07:51:52 +0100	[thread overview]
Message-ID: <a97a0e79-e596-4c57-98f2-212c2b2ce00f@lysator.liu.se> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F1AC@smartserver.smartshare.dk>

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.

  parent reply	other threads:[~2024-01-29  6:51 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-27 18:31 Mattias Rönnblom
2024-01-28 13:52 ` Morten Brørup
2024-01-29  3:02   ` fengchengwen
2024-01-29  6:42     ` Mattias Rönnblom
2024-01-29  6:51   ` Mattias Rönnblom [this message]
2024-01-29  7:38     ` Morten Brørup

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a97a0e79-e596-4c57-98f2-212c2b2ce00f@lysator.liu.se \
    --to=hofors@lysator.liu.se \
    --cc=dev@dpdk.org \
    --cc=mattias.ronnblom@ericsson.com \
    --cc=mb@smartsharesystems.com \
    --cc=techboard@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).