From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id C1A2111F5 for ; Tue, 29 Aug 2017 15:03:15 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Aug 2017 06:03:10 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.41,444,1498546800"; d="scan'208";a="1167223193" Received: from irsmsx151.ger.corp.intel.com ([163.33.192.59]) by orsmga001.jf.intel.com with ESMTP; 29 Aug 2017 06:03:07 -0700 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.49]) by IRSMSX151.ger.corp.intel.com ([169.254.4.108]) with mapi id 14.03.0319.002; Tue, 29 Aug 2017 14:03:06 +0100 From: "Ananyev, Konstantin" To: "Hunt, David" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH v1 0/10] Policy Based Power Control for Guest Thread-Index: AQHTHbujXL6cHFlLjEGMG54Vm8DTZ6KbNsrQ Date: Tue, 29 Aug 2017 13:03:05 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772584F23D987@IRSMSX103.ger.corp.intel.com> References: <1503676941-80981-1-git-send-email-david.hunt@intel.com> In-Reply-To: <1503676941-80981-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: dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v1 0/10] 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: Tue, 29 Aug 2017 13:03:17 -0000 Hi Dave, > This patchset adds the facility for a guest VM to send a policy down to > the 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 > 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 > Firstly, two new API calls are added to the ethdev layer > 1. One to convert a VF id to a PF id. In the patchset > this id is a MAC address. This is needed so that the host can map the = VFs > in the profile to PF so in can monitor the traffic on the relevant PF = at the > host level. > 2. The other function is to read the low-level traffic throughput on the = NIC. > Currently this API reads a NIC register for speed, but we are looking = at > using a more generic way to get these stats, suggestions welcome. Why do you need a server (host) to collect RX/TX statistics for VM? Such method seems to have a lot of limitations: - no clear method to identify to which VM that VF belongs. - rely on HW ability to provide such statistics for PF (limited HW support). - wouldn't work if PF is not controlled by the same DPDK app.=20 Why not to make it client(VM) responsibility to collect that statistics an= d periodically send it to the server?=20 Then server just will have to process that data and make decision. Konstantin >=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 > [01/10] net/i40e: add API to convert VF Id to PF Id > [02/10] net/i40e: add API to get received packet count > [03/10] lib/librte_power: add extra msg type for policies > [04/10] examples/vm_power_mgr: add vcpu to pcpu mapping > [05/10] examples/vm_power_mgr: add scale to medium freq fn > [06/10] examples/vm_power_mgr: add policy to channels > [07/10] examples/vm_power_mgr: add port initialisation > [08/10] examples/guest_cli: add send policy to host > [09/10] examples/vm_power_mgr: set MAC address of VF > [10/10] net/i40e: set register for no drop