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

[Thomas Monjalon <thomas@monjalon.net>]

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?