From: "Wiles, Keith" <keith.wiles@intel.com>
To: "Carrillo, Erik G" <erik.g.carrillo@intel.com>
Cc: "rsanford@akamai.com" <rsanford@akamai.com>,
"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH 0/3] *** timer library enhancements ***
Date: Wed, 23 Aug 2017 15:02:02 +0000 [thread overview]
Message-ID: <3F9B5E47-8083-443E-96EE-CBC41695BE43@intel.com> (raw)
In-Reply-To: <1503499644-29432-1-git-send-email-erik.g.carrillo@intel.com>
> On Aug 23, 2017, at 9:47 AM, Gabriel Carrillo <erik.g.carrillo@intel.com> wrote:
>
> In the current implementation of the DPDK timer library, timers can be
> created and set to be handled by a target lcore by adding it to a
> skiplist that corresponds to that lcore. However, if an application
> enables multiple lcores, and each of these lcores repeatedly attempts
> to install timers on the same target lcore, overall application
> throughput will be reduced as all lcores contend to acquire the lock
> guarding the single skiplist of pending timers.
>
> This patchset addresses this scenario by adding an array of skiplists
> to each lcore's priv_timer struct, such that when lcore i installs a
> timer on lcore k, the timer will be added to the ith skiplist for
> lcore k. If lcore j installs a timer on lcore k simultaneously,
> lcores i and j can both proceed since they will be acquiring different
> locks for different lists.
>
> When lcore k processes its pending timers, it will traverse each skiplist
> in its array and acquire a skiplist's lock while a run list is broken
> out; meanwhile, all other lists can continue to be modified. Then, all
> run lists for lcore k are collected and traversed together so timers are
> executed in their global order.
What is the performance and/or latency added to the timeout now?
I worry about the case when just about all of the cores are enabled, which could be as high was 128 or more now.
One option is to have the lcore j that wants to install a timer on lcore k to pass a message via a ring to lcore k to add that timer. We could even add that logic into setting a timer on a different lcore then the caller in the current API. The ring would be a multi-producer and single consumer, we still have the lock. What am I missing here?
>
> Gabriel Carrillo (3):
> timer: add per-installer pending lists for each lcore
> timer: handle timers installed from non-EAL threads
> doc: update timer lib docs
>
> doc/guides/prog_guide/timer_lib.rst | 19 ++-
> lib/librte_timer/rte_timer.c | 329 +++++++++++++++++++++++-------------
> lib/librte_timer/rte_timer.h | 9 +-
> 3 files changed, 231 insertions(+), 126 deletions(-)
>
> --
> 2.6.4
>
Regards,
Keith
next prev parent reply other threads:[~2017-08-23 15:02 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-23 14:47 Gabriel Carrillo
2017-08-23 14:47 ` [dpdk-dev] [PATCH 1/3] timer: add per-installer pending lists for each lcore Gabriel Carrillo
2017-08-25 20:27 ` [dpdk-dev] [PATCH v2 " Gabriel Carrillo
2017-08-29 10:57 ` Ananyev, Konstantin
2017-08-29 16:13 ` Carrillo, Erik G
2017-08-29 15:11 ` [dpdk-dev] [PATCH " Stephen Hemminger
2017-08-23 14:47 ` [dpdk-dev] [PATCH 2/3] timer: handle timers installed from non-EAL threads Gabriel Carrillo
2017-08-25 20:27 ` [dpdk-dev] [PATCH v2 " Gabriel Carrillo
2017-08-23 14:47 ` [dpdk-dev] [PATCH 3/3] doc: update timer lib docs Gabriel Carrillo
2017-08-25 20:27 ` [dpdk-dev] [PATCH v2 " Gabriel Carrillo
2017-08-23 15:02 ` Wiles, Keith [this message]
2017-08-23 16:19 ` [dpdk-dev] [PATCH 0/3] *** timer library enhancements *** Carrillo, Erik G
2017-08-23 16:50 ` Wiles, Keith
2017-08-23 19:28 ` Carrillo, Erik G
2017-08-23 21:04 ` Wiles, Keith
2017-08-24 14:08 ` Carrillo, Erik G
2017-08-25 20:26 ` [dpdk-dev] [PATCH v2 " Gabriel Carrillo
2017-09-13 22:05 ` [dpdk-dev] [PATCH v3 0/3] timer library enhancement Erik Gabriel Carrillo
2017-09-13 22:05 ` [dpdk-dev] [PATCH v3 1/3] timer: add multiple pending lists option for each lcore Erik Gabriel Carrillo
2017-09-13 22:05 ` [dpdk-dev] [PATCH v3 2/3] timer: handle timers installed from non-EAL threads Erik Gabriel Carrillo
2017-09-13 22:05 ` [dpdk-dev] [PATCH v3 3/3] doc: update timer lib docs Erik Gabriel Carrillo
2017-09-18 16:19 ` Mcnamara, John
2017-09-19 17:04 ` Carrillo, Erik G
2017-09-19 17:02 ` [dpdk-dev] [PATCH v4 0/3] timer library enhancement Erik Gabriel Carrillo
2017-09-19 17:02 ` [dpdk-dev] [PATCH v4 1/3] timer: add multiple pending lists option for each lcore Erik Gabriel Carrillo
2017-09-19 17:02 ` [dpdk-dev] [PATCH v4 2/3] timer: handle timers installed from non-EAL threads Erik Gabriel Carrillo
2017-09-19 17:02 ` [dpdk-dev] [PATCH v4 3/3] doc: update timer lib docs Erik Gabriel Carrillo
2017-10-11 20:42 ` [dpdk-dev] [PATCH v4 0/3] timer library enhancement Thomas Monjalon
2018-04-04 22:42 ` Thomas Monjalon
2018-04-05 21:53 ` Carrillo, Erik G
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=3F9B5E47-8083-443E-96EE-CBC41695BE43@intel.com \
--to=keith.wiles@intel.com \
--cc=dev@dpdk.org \
--cc=erik.g.carrillo@intel.com \
--cc=rsanford@akamai.com \
/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).