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

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



On 22/9/2017 2:03 PM, Thomas Monjalon wrote:
> 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?

Yes, absolutely. And I can then ensure the next version of the policy 
patch-set applies on top of it.

Regards,
Dave.



More information about the dev mailing list