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

[Thomas Monjalon]

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?