On Fri, Feb 27, 2015 at 5:34 PM, Cornelia Huck
<cornelia.h...@de.ibm.com> wrote:
On Fri, 27 Feb 2015 03:42:00 +0008
Jason Wang <jasow...@redhat.com> wrote:
On Thu, Feb 26, 2015 at 8:57 PM, Cornelia Huck
<cornelia.h...@de.ibm.com> wrote:
> On Thu, 26 Feb 2015 15:04:38 +0800
> Jason Wang <jasow...@redhat.com> wrote:
>
>> This patch introduces a bus specific queue limitation. It will
be
>> useful for increasing the limit for one of the bus without
>> disturbing
>> other buses.
>> diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
>> index ffc22e8..5a806b5 100644
>> --- a/hw/virtio/virtio.c
>> +++ b/hw/virtio/virtio.c
>> @@ -541,6 +541,14 @@ void virtio_update_irq(VirtIODevice *vdev)
>> virtio_notify_vector(vdev, VIRTIO_NO_VECTOR);
>> }
>>
>> +int virtio_get_queue_max(VirtIODevice *vdev)
>> +{
>> + BusState *qbus = qdev_get_parent_bus(DEVICE(vdev));
>> + VirtioBusClass *k = VIRTIO_BUS_GET_CLASS(qbus);
>> +
>> + return k->queue_max;
>> +}
>> +
>
> Are all callers of this in the slow path? So we don't introduce
> processing overhead.
Looks not. For overhead, do you mean one introduced by
VIRTIO_BUS_GET_CLASS()? Not sure how much it will affact but we've
already used something like this in the datapath, e.g
virtio_notify_vector().
I may have misremembered how much overhead those types of operation
introduce.
But it made me think: This function is basically introducing a
per-VirtIODevice queue limit. We set it once in the VirtioBusClass
during initialization, but don't expect it to change. Why don't we
just
propagate it to a new member of VirtIODevice during initialization
instead?
The limit may be changed. Consider that patch 9 increases the pci limit
from 64 to 513. But we want to keep the migration compatibility for
legacy machine types e.g machines earlier than pc-q35-2.3 or
pc-i440fx-2.3, so the limit was changed back to 64 in pc_compat_2_2().
More work will be done if we want to propagate it to VirtIODevice, and
it looks unnecessary.
