29/08/2017 15:03, Ananyev, Konstantin: > > 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 via > > virtio-serial. > > > > It's a modification of the vm_power_manager app that runs in the host, and > > the guest_vm_power_app example app that runs in the guest. This allows the > > guest to send down a policy to the host via virtio-serial, which then allows > > 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 need > > 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. > > > > 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" command. > > 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 > > application. > > 6. Send traffic into the VFs at varying traffic rates. > > Observe the frequency change on the host (turbostat -i 1) > > > > The sequence of code changes are as follows: > > > > 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. > Why not to make it client(VM) responsibility to collect that statistics and > periodically send it to the server? > Then server just will have to process that data and make decision.
Any progress Dave? You have another series "turbo boost API". Does it depends on this one?
