From: Brijesh Singh <brijesh.s.singh@gmail.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: Jim Murphy <jmurphy@arista.com>, dev@dpdk.org
Subject: Re: [dpdk-dev] rte_hash thread safe
Date: Tue, 24 Apr 2018 08:04:19 -0700 [thread overview]
Message-ID: <CAAQ1jEHFPwsC=mCbgP+tvud8ZoXs0-Q34d++nVP7gyyE+AFGWA@mail.gmail.com> (raw)
In-Reply-To: <20180423181411.68dadcef@xeon-e3>
Thank you all for explaining. My updates are uncommon; Adding concept
of quiescent threads should be worst case loss of 1 full burst cpu
cycles on the threads. This should be acceptable infrequent delay in
packet processing.
I need data on performance of librcu lookups under infrequent updates,
if the difference is not significant on x86, I will use librcu.
On Mon, Apr 23, 2018 at 6:14 PM, Stephen Hemminger
<stephen@networkplumber.org> wrote:
> On Mon, 23 Apr 2018 17:48:50 -0700
> Jim Murphy <jmurphy@arista.com> wrote:
>
>> Anecdotally I've heard that the urcu hash implementation is slower than
>> rte_hash based on pure lookup performance. Has anyone considered adding RCU
>> hooks into rte_hash?
>
>
> Not really possible with DPDK (as I said earlier) because DPDK does not have concept
> of thread quiescent period to allow for safe deletion. You could manually use RCU
> concepts of RCU and RTE hash; it would require using userspace RCU primitives
> inside DPDK. This would cause a dependency that would prevent that from ever
> being merged upstream due to license conflict; but since DPDK is liberal BSD
> license you are free to do it and maintain it on your own.
next prev parent reply other threads:[~2018-04-24 15:04 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-12 4:12 Brijesh Singh
2018-04-23 19:40 ` Brijesh Singh
2018-04-23 23:50 ` Stephen Hemminger
2018-04-24 0:21 ` Jim Murphy
2018-04-24 0:30 ` Stephen Hemminger
2018-04-24 0:48 ` Jim Murphy
2018-04-24 1:14 ` Stephen Hemminger
2018-04-24 2:13 ` Jim Murphy
2018-04-24 6:36 ` Honnappa Nagarahalli
2018-04-24 15:04 ` Brijesh Singh [this message]
2018-04-25 6:45 ` Shyam Shrivastav
2018-04-24 3:48 ` Jerin Jacob
2018-04-24 5:02 ` Stephen Hemminger
2018-04-24 6:12 ` Honnappa Nagarahalli
2018-04-24 11:03 ` Ananyev, Konstantin
2018-04-24 11:07 ` Bruce Richardson
2018-05-24 17:35 ` Wang, Yipeng1
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='CAAQ1jEHFPwsC=mCbgP+tvud8ZoXs0-Q34d++nVP7gyyE+AFGWA@mail.gmail.com' \
--to=brijesh.s.singh@gmail.com \
--cc=dev@dpdk.org \
--cc=jmurphy@arista.com \
--cc=stephen@networkplumber.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).