test suite reviews and discussions
 help / color / mirror / Atom feed
From: yufengmx <yufengx.mo@intel.com>
To: dts@dpdk.org, lei.a.yao@intel.com
Cc: yufengmx <yufengx.mo@intel.com>
Subject: [dts] [PATCH V2 3/3] test_plans/power_empty_poll: upload test plan
Date: Thu, 24 Oct 2019 09:39:34 +0800	[thread overview]
Message-ID: <20191024013934.67412-4-yufengx.mo@intel.com> (raw)
In-Reply-To: <20191024013934.67412-1-yufengx.mo@intel.com>


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.

Signed-off-by: yufengmx <yufengx.mo@intel.com>
---
 test_plans/power_empty_poll_test_plan.rst | 138 ++++++++++++++++++++++
 1 file changed, 138 insertions(+)
 create mode 100644 test_plans/power_empty_poll_test_plan.rst

diff --git a/test_plans/power_empty_poll_test_plan.rst b/test_plans/power_empty_poll_test_plan.rst
new file mode 100644
index 0000000..61c698c
--- /dev/null
+++ b/test_plans/power_empty_poll_test_plan.rst
@@ -0,0 +1,138 @@
+.. Copyright (c) <2010-2019>, Intel Corporation
+   All rights reserved.
+
+   Redistribution and use in source and binary forms, with or without
+   modification, are permitted provided that the following conditions
+   are met:
+
+   - Redistributions of source code must retain the above copyright
+     notice, this list of conditions and the following disclaimer.
+
+   - Redistributions in binary form must reproduce the above copyright
+     notice, this list of conditions and the following disclaimer in
+     the documentation and/or other materials provided with the
+     distribution.
+
+   - Neither the name of Intel Corporation nor the names of its
+     contributors may be used to endorse or promote products derived
+     from this software without specific prior written permission.
+
+   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+   FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
+   COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
+   INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+   (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+   SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+   HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+   STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+   ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
+   OF THE POSSIBILITY OF SUCH DAMAGE.
+
+=========================
+Power Lib Empty Poll Test
+=========================
+
+Inband Policy Control
+=====================
+
+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.
+
+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.
+
+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.
+
+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.
+
+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.
+
+``training_flag`` : optional, enable/disable training mode. Default value is 0.
+ If the training_flag is set as 1(true), then the application will start in
+ training mode and print out the trained threshold values. If the training_flag
+ is set as 0(false), the application will start in normal mode, and will use
+ either the default thresholds or those supplied on the command line. The
+ trained threshold values are specific to the user’s system, may give a better
+ power profile when compared to the default threshold values.
+
+``med_threshold`` : optional, sets the empty poll threshold of a modestly busy
+system state. If this is not supplied, the application will apply the default
+value of 350000.
+
+``high_threshold`` : optional, sets the empty poll threshold of a busy system
+state. If this is not supplied, the application will apply the default value of
+580000.
+
+
+Preparation Work for Settings
+=============================
+1. Turn on Speedstep option in BIOS
+2. Turn on Turbo in BIOS
+3. Use intel_pstate driver for CPU frequency control
+4. modprobe msr
+
+sys_min=/sys/devices/system/cpu/cpu{}/cpufreq/cpuinfo_min_freq
+sys_max=/sys/devices/system/cpu/cpu{}/cpufreq/cpuinfo_max_freq
+no_turbo_max=$(rdmsr -p 1 0x0CE -f 15:8 -d)00000
+
+cur_min=/sys/devices/system/cpu/cpu{}/cpufreq/scaling_min_freq
+cur_max=/sys/devices/system/cpu/cpu{}/cpufreq/scaling_max_freq
+
+
+Test Case1 : Basic Training mode test based on one NIC with l3fwd-power
+=======================================================================
+Step 1. Bind One NIC to DPDK driver, launch l3fwd-power with empty-poll enabled
+
+    ./l3fwd-power -l 1-2 -n 4 -- -p 0x1 -P --config="(0,0,2)" --empty-poll="1,0,0" -l 10 -m 6 -h 1
+
+Step 2. Check the log also when changing the inject packet rate as following:
+
+    Injected Rate(64B, dst_ip=1.1.1.1): 10G -> 0.1G -> 10G -> 0.1G -> 10G ->
+    0.1G The frequency will be set to MED when we inject 0.1G and return to HGH
+    when inject 10G Rate, check the frequency of the forwarding core(core 2)
+    When traffic is 10G:  cur_min=cur_max=no_turbo_max
+    When traffic is 0.1G: cur_min=cur_max=[no_turbo_max-500000]
+
+
+Test Case2: No-Training mode test based on one NIC with l3fwd-power
+===================================================================
+Step 1. Bind One NIC to DPDK driver, launch l3fwd-power with empty-poll enabled
+
+   ./l3fwd-power -l 1-2 -n 4  -- -p 0x1 -P --config="(0,0,2)" --empty-poll="0,350000,500000" -l 10 -m 6 -h 1
+
+Step 2. Check no training steps are executed in sample's launch log.
-- 
2.21.0


  parent reply	other threads:[~2019-10-24  1:38 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-24  1:39 [dts] [PATCH V2 0/3] power_empty_poll: upload automation script and " yufengmx
2019-10-24  1:39 ` [dts] [PATCH V2 1/3] tests/power_empty_poll: upload automation script yufengmx
2019-10-24  1:39 ` [dts] [PATCH V2 2/3] test_plans/power_empty_poll: add test plan index yufengmx
2019-10-24  1:39 ` yufengmx [this message]
2019-11-04  2:37 ` [dts] [PATCH V2 0/3] power_empty_poll: upload automation script and test plan Tu, Lijuan

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=20191024013934.67412-4-yufengx.mo@intel.com \
    --to=yufengx.mo@intel.com \
    --cc=dts@dpdk.org \
    --cc=lei.a.yao@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).