Matias Ezequiel Vara Larsen <[email protected]> writes:
> On Mon, Jul 10, 2023 at 04:35:09PM +0100, Alex Bennée wrote: >> In theory we shouldn't need to repeat so much boilerplate to support >> vhost-user backends. This provides a generic vhost-user-base QOM >> object and a derived vhost-user-device for which the user needs to >> provide the few bits of information that aren't currently provided by >> the vhost-user protocol. This should provide a baseline implementation >> from which the other vhost-user stub can specialise. >> >> Signed-off-by: Alex Bennée <[email protected]> >> >> --- >> v2 >> - split into vub and vud <snip> >> + >> + /* >> + * Disable guest notifiers, by default all notifications will be via the >> + * asynchronous vhost-user socket. >> + */ >> + vdev->use_guest_notifier_mask = false; >> + >> + /* Allocate queues */ >> + vub->vqs = g_ptr_array_sized_new(vub->num_vqs); >> + for (int i = 0; i < vub->num_vqs; i++) { >> + g_ptr_array_add(vub->vqs, >> + virtio_add_queue(vdev, 4, vub_handle_output)); >> + } >> + > > Hello Alex, apologies if someone already asked this. If I understand > correctly, the second parameter of virtio_add_queue() is the len of the > queue. Why have you chosen "4" as its value? Shall qemu query the len of > the queue from the vhost-user device instead? Hmm yeah that is inherited from the virtio-rng backend which has a pretty short queue. I don't think it is intrinsic to the device implementation (although I guess that depends if a device will have multiple requests in flight). I propose making is some useful ^2 (like 64) and adding a config knob to increase it if needed. -- Alex Bennée Virtualisation Tech Lead @ Linaro
