[dpdk-dev] [PATCH v1 0/10] Policy Based Power Control for Guest

Hunt, David david.hunt at intel.com
Fri Sep 22 12:28:15 CEST 2017



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.



More information about the dev mailing list