On Tue, Sep 05, 2023 at 06:01:56PM +0100, Alex Bennée wrote:
>
> Matias Ezequiel Vara Larsen <mvara...@redhat.com> 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 <alex.ben...@linaro.org>
> >>
> >> ---
> >> 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.
>
LGTM.
Matias
_______________________________________________
Virtio-fs mailing list
Virtio-fs@redhat.com
https://listman.redhat.com/mailman/listinfo/virtio-fs
