From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 779A91B225 for ; Thu, 5 Oct 2017 15:54:33 +0200 (CEST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Oct 2017 06:54:32 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,481,1500966000"; d="scan'208";a="1202578683" Received: from irsmsx103.ger.corp.intel.com ([163.33.3.157]) by fmsmga001.fm.intel.com with ESMTP; 05 Oct 2017 06:54:31 -0700 Received: from irsmsx111.ger.corp.intel.com (10.108.20.4) by IRSMSX103.ger.corp.intel.com (163.33.3.157) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 5 Oct 2017 14:54:28 +0100 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.49]) by irsmsx111.ger.corp.intel.com ([169.254.2.30]) with mapi id 14.03.0319.002; Thu, 5 Oct 2017 14:54:27 +0100 From: "Ananyev, Konstantin" To: "Hunt, David" , "dev@dpdk.org" CC: "Wu, Jingjing" , "santosh.shukla@caviumnetworks.com" Thread-Topic: [PATCH v7 0/9] Policy Based Power Control for Guest Thread-Index: AQHTPd3Ud0w5Lh2f+keWwKx/G4sHOqLVRvaQ Date: Thu, 5 Oct 2017 13:54:27 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772585FAA4CAA@IRSMSX103.ger.corp.intel.com> References: <1507206350-215367-1-git-send-email-david.hunt@intel.com> <1507210100-69917-1-git-send-email-david.hunt@intel.com> In-Reply-To: <1507210100-69917-1-git-send-email-david.hunt@intel.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMDdmYjQ3ZTItZDMwMS00YTdlLTkyNDEtNzcxYjkwYjNmOTM0IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6IlpSYlVGRldlZkJqYTVtd05RUWVFNmc3NmZPYVdZNmU5am9SVnhhNHluTkk9In0= x-ctpclassification: CTP_IC dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v7 0/9] Policy Based Power Control for Guest X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 13:54:34 -0000 > -----Original Message----- > From: Hunt, David > Sent: Thursday, October 5, 2017 2:28 PM > To: dev@dpdk.org > Cc: Ananyev, Konstantin ; Wu, Jingjing ; santosh.shukla@caviumnetworks.com > Subject: [PATCH v7 0/9] Policy Based Power Control for Guest >=20 > Policy Based Power Control for Guest >=20 > This patchset adds the facility for a guest VM to send a policy down to t= he > host that will allow the host to scale up/down cpu frequencies > depending on the policy criteria independently of the DPDK app running in > the guest. This differs from the previous vm_power implementation where > individual scale up/down requests were send from the guest to the host vi= a > virtio-serial. >=20 > V7 patchset changes: > * Changed return code of rte_pmd_i40e_query_vfid_by_mac() from an > int64_t to int >=20 > V6 patchset changes: > * Fixed comments in header for rte_pmd_i40e_query_vfid_by_mac. > * changed rte_pmd_i40e_query_vfid_by_mac return code from uint to int > as it can return negative error codes. > * Removed bool enum from channel_commands.h, including stdbool.h instea= d. > * Added #define VM_MAX_NAME_SZ 32 to channel_commands.h > * Renamed a few variables to be more readable. > * Added returns in a few places if failed to get info on domain. > * Fixed power_manager_init to keep track of num_freqs for each core. > * In power_manager_scale_core_med(), changed a hardcoded '5' to instead > be calculated from the centre of the frequency list > (global_core_freq_info[core_num].num_freqs / 2) >=20 > V5 patchset changes: > * Removed most of the #ifdef I40_PMD as it will be applicable to > other PMDs in the future. > * Changed the parameter of rte_pmd_i40e_query_vfid_by_mac from a uint64 > to a const struct ether_addr *, rather than casting it later in the > function. >=20 > V4 patchset changes: > * None, re-post to mailing list under the correct email thread. >=20 > V3 patchset changes: > * Changed to using is_same_ether_addr() instead of looping through > the mac address bytes to compare them. > * Tweaked some comments and working in the i40e patch after review. > * Added a patch to the set to add new i40e function to map file, so > as to allow shared library builds. The power library API needs a clea= nup > in next release, so will add API/ABI warning for this cleanup in a > separate patch. >=20 > V2 patchset changes: > * Removed API's in ethdev layer. > * Now just a single new API in the i40e driver for mapping VF MAC to > VF index. > * Moved new function from rte_rxtx.c to rte_pmd_i40e.c > * Removed function for reading i40e register, moved to using the > standard stats API. > * Renamed i40e function to rte_pmd_i40e_query_vfid_by_mac > * Cleaned up policy generation code. >=20 > It's a modification of the vm_power_manager app that runs in the host, an= d > the guest_vm_power_app example app that runs in the guest. This allows th= e > guest to send down a policy to the host via virtio-serial, which then all= ows > the host to scale up/down based on the criteria in the policy, resulting = in > quicker scale up/down than individual requests coming from the guest. > It also means that the DPDK application running in the guest does not nee= d > to be modified in any way, it is unaware that it's cores are being scaled > up/down, reducing the effort in implementing a power-aware infrastructure= . >=20 > The usage model is as follows: > 1. Set up the VF's and assign to the guest in the usual way. > 2. run vm_power_manager on the host, creating a channel to the guest. > 3. Start the guest_vm_power_mgr app on the guest, which establishes > a virtio-serial channel to the host. > 4. Send down the profile for the guest using the "send_profile now" comma= nd. > There is an example profile hard-coded into guest_vm_power_mgr. > 5. Stop the guest_vm_power_mgr and run your normal power-unaware applicat= ion. > 6. Send traffic into the VFs at varying traffic rates. > Observe the frequency change on the host (turbostat -i 1) >=20 > The sequence of code changes are as follows: >=20 > A new function has been aded to the i40e driver to allow mapping of > a VF MAC to VF index. >=20 > Next we make an addition to librte_power that adds an extra command to al= low > the passing of a policy structure from the guest to the host. This struct > contains information like busy/quiet hour, packet throughput thresholds, = etc. >=20 > The next addition adds functionality to convert the virtual CPU (vcpU0 ID= s to > physical CPU (pcpu) IDs so that the host can scale up/down the cores used > in the guest. >=20 > The remaining patches are functionality to process the policy, and take a= ction > when the relevant trigger occurs to cause a frequency change. >=20 > [1/9] net/i40e: add API to convert VF MAC to VF id > [2/9] lib/librte_power: add extra msg type for policies > [3/9] examples/vm_power_mgr: add vcpu to pcpu mapping > [4/9] examples/vm_power_mgr: add scale to medium freq fn > [5/9] examples/vm_power_mgr: add policy to channels > [6/9] examples/vm_power_mgr: add port initialisation > [7/9] power: add send channel msg function to map file > [8/9] examples/guest_cli: add send policy to host > [9/9] examples/vm_power_mgr: set MAC address of VF Acked-by: Konstantin Ananyev