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.
Regards,
Dave.
