Patch Detail
get:
Show a patch.
patch:
Update a patch.
put:
Update a patch.
GET /api/patches/44811/?format=api
{ "id": 44811, "url": "https://patches.dpdk.org/api/patches/44811/?format=api", "web_url": "https://patches.dpdk.org/project/dpdk/patch/1537191016-26330-3-git-send-email-liang.j.ma@intel.com/", "project": { "id": 1, "url": "https://patches.dpdk.org/api/projects/1/?format=api", "name": "DPDK", "link_name": "dpdk", "list_id": "dev.dpdk.org", "list_email": "dev@dpdk.org", "web_url": "http://core.dpdk.org", "scm_url": "git://dpdk.org/dpdk", "webscm_url": "http://git.dpdk.org/dpdk", "list_archive_url": "https://inbox.dpdk.org/dev", "list_archive_url_format": "https://inbox.dpdk.org/dev/{}", "commit_url_format": "" }, "msgid": "<1537191016-26330-3-git-send-email-liang.j.ma@intel.com>", "list_archive_url": "https://inbox.dpdk.org/dev/1537191016-26330-3-git-send-email-liang.j.ma@intel.com", "date": "2018-09-17T13:30:15", "name": "[v8,3/4] doc/guides/proguide/power-man: update the power API", "commit_ref": null, "pull_url": null, "state": "superseded", "archived": true, "hash": "f963e55607fae725a1ff0dde2a6504736026c358", "submitter": { "id": 904, "url": "https://patches.dpdk.org/api/people/904/?format=api", "name": "Liang, Ma", "email": "liang.j.ma@intel.com" }, "delegate": { "id": 1, "url": "https://patches.dpdk.org/api/users/1/?format=api", "username": "tmonjalo", "first_name": "Thomas", "last_name": "Monjalon", "email": "thomas@monjalon.net" }, "mbox": "https://patches.dpdk.org/project/dpdk/patch/1537191016-26330-3-git-send-email-liang.j.ma@intel.com/mbox/", "series": [ { "id": 1356, "url": "https://patches.dpdk.org/api/series/1356/?format=api", "web_url": "https://patches.dpdk.org/project/dpdk/list/?series=1356", "date": "2018-09-17T13:30:15", "name": "[v8,1/4] lib/librte_power: traffic pattern aware power control", "version": 8, "mbox": "https://patches.dpdk.org/series/1356/mbox/" } ], "comments": "https://patches.dpdk.org/api/patches/44811/comments/", "check": "success", "checks": "https://patches.dpdk.org/api/patches/44811/checks/", "tags": {}, "related": [], "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@dpdk.org", "Delivered-To": "patchwork@dpdk.org", "Received": [ "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id E438A1AEE8;\n\tMon, 17 Sep 2018 15:30:31 +0200 (CEST)", "from mga18.intel.com (mga18.intel.com [134.134.136.126])\n\tby dpdk.org (Postfix) with ESMTP id 8D1398E7F\n\tfor <dev@dpdk.org>; Mon, 17 Sep 2018 15:30:30 +0200 (CEST)", "from fmsmga001.fm.intel.com ([10.253.24.23])\n\tby orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t17 Sep 2018 06:30:29 -0700", "from irvmail001.ir.intel.com ([163.33.26.43])\n\tby fmsmga001.fm.intel.com with ESMTP; 17 Sep 2018 06:30:24 -0700", "from sivswdev01.ir.intel.com (sivswdev01.ir.intel.com\n\t[10.237.217.45])\n\tby irvmail001.ir.intel.com (8.14.3/8.13.6/MailSET/Hub) with ESMTP id\n\tw8HDUNd6030936; Mon, 17 Sep 2018 14:30:23 +0100", "from sivswdev01.ir.intel.com (localhost [127.0.0.1])\n\tby sivswdev01.ir.intel.com with ESMTP id w8HDUNJW026458;\n\tMon, 17 Sep 2018 14:30:23 +0100", "(from lma25@localhost)\n\tby sivswdev01.ir.intel.com with LOCAL id w8HDUNE3026454;\n\tMon, 17 Sep 2018 14:30:23 +0100" ], "X-Amp-Result": "SKIPPED(no attachment in message)", "X-Amp-File-Uploaded": "False", "X-ExtLoop1": "1", "X-IronPort-AV": "E=Sophos;i=\"5.53,385,1531810800\"; d=\"scan'208\";a=\"90778061\"", "From": "Liang Ma <liang.j.ma@intel.com>", "To": "david.hunt@intel.com", "Cc": "dev@dpdk.org, lei.a.yao@intel.com, ktraynor@redhat.com,\n\tjohn.geary@intel.com, Liang Ma <liang.j.ma@intel.com>", "Date": "Mon, 17 Sep 2018 14:30:15 +0100", "Message-Id": "<1537191016-26330-3-git-send-email-liang.j.ma@intel.com>", "X-Mailer": "git-send-email 1.7.7.4", "In-Reply-To": "<1537191016-26330-1-git-send-email-liang.j.ma@intel.com>", "References": "<1536070228-6545-1-git-send-email-liang.j.ma@intel.com>\n\t<1537191016-26330-1-git-send-email-liang.j.ma@intel.com>", "Subject": "[dpdk-dev] [PATCH v8 3/4] doc/guides/proguide/power-man: update the\n\tpower API", "X-BeenThere": "dev@dpdk.org", "X-Mailman-Version": "2.1.15", "Precedence": "list", "List-Id": "DPDK patches and discussions <dev.dpdk.org>", "List-Unsubscribe": "<https://mails.dpdk.org/options/dev>,\n\t<mailto:dev-request@dpdk.org?subject=unsubscribe>", "List-Archive": "<http://mails.dpdk.org/archives/dev/>", "List-Post": "<mailto:dev@dpdk.org>", "List-Help": "<mailto:dev-request@dpdk.org?subject=help>", "List-Subscribe": "<https://mails.dpdk.org/listinfo/dev>,\n\t<mailto:dev-request@dpdk.org?subject=subscribe>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "content": "Update the document for empty poll API.\n\nSigned-off-by: Liang Ma <liang.j.ma@intel.com>\n---\n doc/guides/prog_guide/power_man.rst | 90 +++++++++++++++++++++++++++++++++++++\n 1 file changed, 90 insertions(+)", "diff": "diff --git a/doc/guides/prog_guide/power_man.rst b/doc/guides/prog_guide/power_man.rst\nindex eba1cc6..056cb12 100644\n--- a/doc/guides/prog_guide/power_man.rst\n+++ b/doc/guides/prog_guide/power_man.rst\n@@ -106,6 +106,96 @@ User Cases\n \n The power management mechanism is used to save power when performing L3 forwarding.\n \n+\n+Empty Poll API\n+--------------\n+\n+Abstract\n+~~~~~~~~\n+\n+For packet processing workloads such as DPDK polling is continuous.\n+This means CPU cores always show 100% busy independent of how much work\n+those cores are doing. It is critical to accurately determine how busy\n+a core is hugely important for the following reasons:\n+\n+ * No indication of overload conditions\n+ * User do not know how much real load is on a system meaning\n+ resulted in wasted energy as no power management is utilized\n+\n+Compared to the original l3fwd-power design, instead of going to sleep\n+after detecting an empty poll, the new mechanism just lowers the core frequency.\n+As a result, the application does not stop polling the device, which leads\n+to improved handling of bursts of traffic.\n+\n+When the system become busy, the empty poll mechanism can also increase the core\n+frequency (including turbo) to do best effort for intensive traffic. This gives\n+us more flexible and balanced traffic awareness over the standard l3fwd-power\n+application.\n+\n+\n+Proposed Solution\n+~~~~~~~~~~~~~~~~~\n+The proposed solution focuses on how many times empty polls are executed.\n+The less the number of empty polls, means current core is busy with processing\n+workload, therefore, the higher frequency is needed. The high empty poll number\n+indicates the current core not doing any real work therefore, we can lower the\n+frequency to safe power.\n+\n+In the current implementation, each core has 1 empty-poll counter which assume\n+1 core is dedicated to 1 queue. This will need to be expanded in the future to\n+support multiple queues per core.\n+\n+Power state definition:\n+^^^^^^^^^^^^^^^^^^^^^^^\n+\n+* LOW: Not currently used, reserved for future use.\n+\n+* MED: the frequency is used to process modest traffic workload.\n+\n+* HIGH: the frequency is used to process busy traffic workload.\n+\n+There are two phases to establish the power management system:\n+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n+* Initialization/Training phase. The training phase is necessary\n+ in order to figure out the system polling baseline numbers from\n+ idle to busy. The highest poll count will be during idle, where all\n+ polls are empty. These poll counts will be different between\n+ systems due to the many possible processor micro-arch, cache\n+ and device configurations, hence the training phase.\n+ In the training phase, traffic is blocked so the training algorithm\n+ can average the empty-poll numbers for the LOW, MED and\n+ HIGH power states in order to create a baseline.\n+ The core's counter are collected every 10ms, and the Training\n+ phase will take 2 seconds.\n+ Training is disabled as default configuration.\n+ The default parameter is applied. Simple App still can trigger\n+ training if that's needed\n+\n+* Normal phase. When the training phase is complete, traffic is\n+ started. The run-time poll counts are compared with the\n+ baseline and the decision will be taken to move to MED power\n+ state or HIGH power state. The counters are calculated every\n+ 10ms.\n+\n+\n+API Overview for Empty Poll Power Management\n+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n+* **State Init**: initialize the power management system.\n+\n+* **State Free**: free the resource hold by power management system.\n+\n+* **Update Empty Poll Counter**: update the empty poll counter.\n+\n+* **Update Valid Poll Counter**: update the valid poll counter.\n+\n+* **Set the Fequence Index**: update the power state/frequency mapping.\n+\n+* **Detect empty poll state change**: empty poll state change detection algorithm then take action.\n+\n+User Cases\n+----------\n+The mechanism can applied to any device which is based on polling. e.g. NIC, FPGA.\n+\n References\n ----------\n \n", "prefixes": [ "v8", "3/4" ] }