22/09/2017 12:28, Hunt, David: > > On 22/9/2017 10:51 AM, Thomas Monjalon wrote: > > 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? > > Hi Thomas, > > We're still working on updates based on Konstantin's feedback above, and > hope to have a new patch set submitted to the mailing list early next > week. This will remove the ethdev layer changes, and uses pre-existing > stats-api. > > In relation to the Turbo patch, they are still independent, but when we > have the next revision of the Policy patch submitted, I'll do a new > version of the Turbo patch so that it can be applied on top of the > policy patch.
OK, thanks If the turbo patch is independent, I can push it now?
