I had replied to this message, but my reply never got to the list.
Let's try again.
I wonder if this might be papering over a bug in the host cpufreq
driver. If the guest is not doing much and leaving a lot of idle CPU
time, the host should scale down the frequency of that CPU. In the case
of pi
On 12/12/2014 14:00, Carew, Alan wrote:
> The problem is deterministic control of host CPU frequency and the DPDK usage
> model.
> A hands-off power governor will scale based on workload, whether this is a
> host
> application or VM, so no problems or bug there.
>
> Where this solution fits is
On 12/12/2014 17:10, Thomas Monjalon wrote:
> > Ok, this looks specific enough that an out-of-band solution within DPDK
> > sounds like the best approach. It seems unnecessary to involve the
> > hypervisor (neither KVM nor QEMU).
>
> Paolo, I don't understand why you don't imagine controlling fr
On 13/12/2017 09:51, Maxime Coquelin wrote:
> This series fixes this by destroying all but first queue pair in
> the backend if VIRTIO_NET_F_MQ isn't negotiated. First patches
> makes sure that VHOST_USER_SET_FEATURES request doesn't change
> Virtio features while the device is running, which shoul
On 13/12/2017 11:11, Maxime Coquelin wrote:
>> Hi Maxime,
>>
>> I think this series is wrong from the virtio spec's point of view. If
>> the driver requests VIRTIO_NET_F_MQ, that does not mean "the driver
>> knows about multiqueue", it only means that "the driver wants to read
>> max_virtqueue_pai
5 matches
Mail list logo
