On Fri, 27 Feb 2015 03:42:00 +0008
Jason Wang <address@hidden> wrote:
On Thu, Feb 26, 2015 at 8:57 PM, Cornelia Huck
<address@hidden> wrote:
> On Thu, 26 Feb 2015 15:04:38 +0800
> Jason Wang <address@hidden> 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?