From: Kevin Traynor <ktraynor@redhat.com>
To: Radu Nicolau <radu.nicolau@intel.com>,
dev@dpdk.org, liang.j.ma@intel.com
Cc: david.hunt@intel.com
Subject: Re: [dpdk-dev] [PATCH v4 1/2] lib/librte_power: traffic pattern aware power control
Date: Wed, 27 Jun 2018 18:33:04 +0100 [thread overview]
Message-ID: <014ba7a7-c9a7-86da-e705-a688e53b83b3@redhat.com> (raw)
In-Reply-To: <1530013217-22300-1-git-send-email-radu.nicolau@intel.com>
On 06/26/2018 12:40 PM, Radu Nicolau wrote:
> From: Liang Ma <liang.j.ma@intel.com>
>
> 1. Abstract
>
> For packet processing workloads such as DPDK polling is continuous.
> This means CPU cores always show 100% busy independent of how much work
> those cores are doing. It is critical to accurately determine how busy
> a core is hugely important for the following reasons:
>
> * No indication of overload conditions
>
> * User do not know how much real load is on a system meaning resulted in
> wasted energy as no power management is utilized
>
> Tried and failed schemes include calculating the cycles required from
> the load on the core, in other words the busyness. For example,
> how many cycles it costs to handle each packet and determining the
> frequency cost per core. Due to the varying nature of traffic, types of
> frames and cost in cycles to process, this mechanism becomes complex
> quickly where a simple scheme is required to solve the problems.
>
> 2. Proposed solution
>
> For all polling mechanism, the proposed solution focus on how many times
> empty poll executed instead of calculating how many cycles it cost to
> handle each packet. The less empty poll number means current core is busy
> with processing workload, therefore, the higher frequency is needed. The
> high empty poll number indicate current core has lots spare time,
> therefore, we can lower the frequency.
>
Hi Liang/Radu,
I can see the benefit of providing an API for the application to provide
the num rx from each poll, and then have the library step down/up the
freq based on that. However, not sure I follow why you are adding the
complexity of defining power states and training modes.
> 2.1 Power state definition:
>
> LOW: the frequency is used for purge mode.
>
> MED: the frequency is used to process modest traffic workload.
>
> HIGH: the frequency is used to process busy traffic workload.
>
Why does there need to be user defined freq levels? Why not just keep
stepping down the freq until there is some user-defined threshold of
zero polls reached. e.g. keep stepping down until 10% of polls are zero
poll and have a tail of some time (perhaps user defined) for the step down.
> 2.2 There are two phases to establish the power management system:
>
> a.Initialization/Training phase. There is no traffic pass-through,
> the system will test average empty poll numbers with
> LOW/MED/HIGH power state. Those average empty poll numbers
> will be the baseline
> for the normal phase. The system will collect all core's counter
> every 100ms. The Training phase will take 5 seconds.
>
This is requiring an application to sit for 5 secs in order to train and
align poll numbers with states? That doesn't seem realistic to me.
> b.Normal phase. When the real traffic pass-though, the system will
> compare run-time empty poll moving average value with base line
> then make decision to move to HIGH power state of MED power
> state. The system will collect all core's counter every 10ms.
>
I only reviewed this commit msg and API usage, so maybe I didn't fully
get the use case or details, but it seems quite awkward from an
application perspective IMHO.
> 3. Proposed API
>
> 1. rte_power_empty_poll_stat_init(void);
> which is used to initialize the power management system.
>
> 2. rte_power_empty_poll_stat_free(void);
> which is used to free the resource hold by power management system.
>
> 3. rte_power_empty_poll_stat_update(unsigned int lcore_id);
> which is used to update specific core empty poll counter, not thread safe
>
> 4. rte_power_poll_stat_update(unsigned int lcore_id, uint8_t nb_pkt);
> which is used to update specific core valid poll counter, not thread safe
>
I think 4 could be dropped and 3 used instead. It could be a simple API
that takes in the core and nb_pkts from a poll. Seems clearer than
making a separate API for a special value of nb_pkts (i.e. 0) and the
application having to check to know which API should be called.
> 5. rte_power_empty_poll_stat_fetch(unsigned int lcore_id);
> which is used to get specific core empty poll counter.
>
> 6. rte_power_poll_stat_fetch(unsigned int lcore_id);
> which is used to get specific core valid poll counter.
>
> 7. rte_power_empty_poll_set_freq(enum freq_val index, uint32_t limit);
> which allow user customize the frequency of power state.
>
> 8. rte_power_empty_poll_setup_timer(void);
> which is used to setup the timer/callback to process all above counter.
>
The new API should be experimental
> ChangeLog:
> v2: fix some coding style issues
> v3: rename the filename, API name.
> v4: updated makefile and symbol list
>
> Signed-off-by: Liang Ma <liang.j.ma@intel.com>
> Signed-off-by: Radu Nicolau <radu.nicolau@intel.com>
> ---
> lib/librte_power/Makefile | 5 +-
> lib/librte_power/meson.build | 5 +-
> lib/librte_power/rte_power_empty_poll.c | 521 ++++++++++++++++++++++++++++++++
> lib/librte_power/rte_power_empty_poll.h | 202 +++++++++++++
> lib/librte_power/rte_power_version.map | 14 +-
> 5 files changed, 742 insertions(+), 5 deletions(-)
> create mode 100644 lib/librte_power/rte_power_empty_poll.c
> create mode 100644 lib/librte_power/rte_power_empty_poll.h
>
Is there any in-tree documentation planned?
Kevin.
next prev parent reply other threads:[~2018-06-27 17:33 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-08 9:57 [dpdk-dev] [PATCH v1 " Liang Ma
2018-06-08 9:57 ` [dpdk-dev] [PATCH v1 2/2] examples/l3fwd-power: simple app update to support new API Liang Ma
2018-06-19 10:31 ` Hunt, David
2018-06-08 15:26 ` [dpdk-dev] [PATCH v2 1/2] lib/librte_power: traffic pattern aware power control Liang Ma
2018-06-08 15:26 ` [dpdk-dev] [PATCH v2 2/2] examples/l3fwd-power: simple app update to support new API Liang Ma
2018-06-20 14:44 ` [dpdk-dev] [PATCH v3 1/2] lib/librte_power: traffic pattern aware power control Liang Ma
2018-06-20 14:44 ` [dpdk-dev] [PATCH v3 2/2] examples/l3fwd-power: simple app update to support new API Liang Ma
2018-06-26 11:40 ` [dpdk-dev] [PATCH v4 1/2] lib/librte_power: traffic pattern aware power control Radu Nicolau
2018-06-26 11:40 ` [dpdk-dev] [PATCH v4 2/2] examples/l3fwd-power: simple app update to support new API Radu Nicolau
2018-06-26 13:03 ` Hunt, David
2018-06-26 13:03 ` [dpdk-dev] [PATCH v4 1/2] lib/librte_power: traffic pattern aware power control Hunt, David
2018-06-27 17:33 ` Kevin Traynor [this message]
2018-07-05 14:45 ` Liang, Ma
2018-07-12 17:30 ` Thomas Monjalon
2018-09-11 9:19 ` Hunt, David
2018-09-13 9:46 ` Kevin Traynor
2018-09-13 13:30 ` Liang, Ma
2018-07-10 16:04 ` [dpdk-dev] [PATCH v5 " Radu Nicolau
2018-07-10 16:04 ` [dpdk-dev] [PATCH v5 2/2] examples/l3fwd-power: simple app update to support new API Radu Nicolau
2018-08-31 15:04 ` [dpdk-dev] [PATCH v6 1/4] lib/librte_power: traffic pattern aware power control Liang Ma
2018-08-31 15:04 ` [dpdk-dev] [PATCH v6 2/4] examples/l3fwd-power: simple app update for new API Liang Ma
2018-08-31 15:04 ` [dpdk-dev] [PATCH v6 3/4] doc/guides/proguides/power-man: update the power API Liang Ma
2018-08-31 15:04 ` [dpdk-dev] [PATCH v6 4/4] doc/guides/sample_app_ug/l3_forward_power_man.rst: empty poll update Liang Ma
2018-09-04 1:11 ` [dpdk-dev] [PATCH v6 1/4] lib/librte_power: traffic pattern aware power control Yao, Lei A
2018-09-04 2:09 ` Yao, Lei A
2018-09-04 14:10 ` [dpdk-dev] [PATCH v7 " Liang Ma
2018-09-04 14:10 ` [dpdk-dev] [PATCH v7 2/4] examples/l3fwd-power: simple app update for new API Liang Ma
2018-09-04 14:10 ` [dpdk-dev] [PATCH v7 3/4] doc/guides/proguides/power-man: update the power API Liang Ma
2018-09-04 14:10 ` [dpdk-dev] [PATCH v7 4/4] doc/guides/sample_app_ug/l3_forward_power_man.rst: empty poll update Liang Ma
2018-09-13 10:54 ` [dpdk-dev] [PATCH v7 1/4] lib/librte_power: traffic pattern aware power control Kevin Traynor
2018-09-13 13:37 ` Liang, Ma
2018-09-13 14:05 ` Hunt, David
2018-09-17 13:30 ` [dpdk-dev] [PATCH v8 " Liang Ma
2018-09-17 13:30 ` [dpdk-dev] [PATCH v8 2/4] examples/l3fwd-power: simple app update for new API Liang Ma
2018-09-28 11:19 ` Hunt, David
2018-10-02 10:18 ` Liang, Ma
2018-09-17 13:30 ` [dpdk-dev] [PATCH v8 3/4] doc/guides/proguide/power-man: update the power API Liang Ma
2018-09-25 12:31 ` Kovacevic, Marko
2018-09-25 12:44 ` Kovacevic, Marko
2018-09-28 12:30 ` Hunt, David
2018-09-17 13:30 ` [dpdk-dev] [PATCH v8 4/4] doc/guides/sample_app_ug/l3_forward_power_man.rst: empty poll update Liang Ma
2018-09-25 13:20 ` Kovacevic, Marko
2018-09-28 12:43 ` Hunt, David
2018-09-28 12:52 ` Liang, Ma
2018-09-28 10:47 ` [dpdk-dev] [PATCH v8 1/4] lib/librte_power: traffic pattern aware power control Hunt, David
2018-10-02 10:13 ` Liang, Ma
2018-09-28 14:58 ` [dpdk-dev] [PATCH v9 " Liang Ma
2018-09-28 14:58 ` [dpdk-dev] [PATCH v9 2/4] examples/l3fwd-power: simple app update for new API Liang Ma
2018-09-28 14:58 ` [dpdk-dev] [PATCH v9 3/4] doc/guides/pro_guide/power-man: update the power API Liang Ma
2018-10-02 13:48 ` [dpdk-dev] [PATCH v10 1/4] lib/librte_power: traffic pattern aware power control Liang Ma
2018-10-02 13:48 ` [dpdk-dev] [PATCH v10 2/4] examples/l3fwd-power: simple app update for new API Liang Ma
2018-10-02 14:23 ` Hunt, David
2018-10-02 13:48 ` [dpdk-dev] [PATCH v10 3/4] doc/guides/pro_guide/power-man: update the power API Liang Ma
2018-10-02 14:24 ` Hunt, David
2018-10-02 13:48 ` [dpdk-dev] [PATCH v10 4/4] doc/guides/sample_app_ug/l3_forward_power_man.rst: update Liang Ma
2018-10-02 14:25 ` Hunt, David
2018-10-02 14:22 ` [dpdk-dev] [PATCH v10 1/4] lib/librte_power: traffic pattern aware power control Hunt, David
2018-10-12 1:59 ` Yao, Lei A
2018-10-12 10:02 ` Liang, Ma
2018-10-12 13:22 ` Yao, Lei A
2018-10-19 10:23 ` [dpdk-dev] [PATCH v11 1/5] " Liang Ma
2018-10-19 10:23 ` [dpdk-dev] [PATCH v11 2/5] examples/l3fwd-power: simple app update for new API Liang Ma
2018-10-19 10:23 ` [dpdk-dev] [PATCH v11 3/5] doc/guides/pro_guide/power-man: update the power API Liang Ma
2018-10-19 10:23 ` [dpdk-dev] [PATCH v11 5/5] doc: update release notes for empty poll library Liang Ma
2018-10-19 11:07 ` [dpdk-dev] [PATCH v12 1/5] lib/librte_power: traffic pattern aware power control Liang Ma
2018-10-19 11:07 ` [dpdk-dev] [PATCH v12 2/5] examples/l3fwd-power: simple app update for new API Liang Ma
2018-10-19 11:07 ` [dpdk-dev] [PATCH v12 3/5] doc/guides/pro_guide/power-man: update the power API Liang Ma
2018-10-19 11:07 ` [dpdk-dev] [PATCH v12 4/5] doc/guides/sample_app_ug/l3_forward_power_man.rst: update Liang Ma
2018-10-19 11:07 ` [dpdk-dev] [PATCH v12 5/5] doc: update release notes for empty poll library Liang Ma
2018-10-22 12:41 ` Kovacevic, Marko
2018-10-25 23:39 ` Thomas Monjalon
2018-10-25 23:22 ` [dpdk-dev] [PATCH v12 1/5] lib/librte_power: traffic pattern aware power control Thomas Monjalon
2018-10-25 23:32 ` Thomas Monjalon
2018-10-25 23:54 ` Thomas Monjalon
2018-10-25 23:55 ` Thomas Monjalon
2018-10-26 13:34 ` Liang, Ma
2018-10-01 10:06 ` [dpdk-dev] [PATCH v9 4/4] doc/guides/sample_app_ug/l3_forward_power_man.rst: empty poll update Liang Ma
2018-06-14 10:59 ` [dpdk-dev] [PATCH v1 1/2] lib/librte_power: traffic pattern aware power control Hunt, David
2018-06-18 16:11 ` Liang, Ma
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=014ba7a7-c9a7-86da-e705-a688e53b83b3@redhat.com \
--to=ktraynor@redhat.com \
--cc=david.hunt@intel.com \
--cc=dev@dpdk.org \
--cc=liang.j.ma@intel.com \
--cc=radu.nicolau@intel.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).