On 2018/11/3 上午12:07, Vitaly Mayatskikh wrote:
> +
> +static int vhost_vq_poll_start(struct vhost_virtqueue *vq)
> +{
> + if (!vq->worker) {
> + vq->worker = kthread_create(vhost_vq_worker, vq, "vhost-%d/%i",
> + vq->dev->pid, vq->index);
> + if (IS_ERR(vq->worker)) {
> + int ret = PTR_ERR(vq->worker);
> +
> + pr_err("%s: can't create vq worker: %d\n", __func__,
> + ret);
> + vq->worker = NULL;
> + return ret;
> + }
> + }
> + vhost_work_init(&vq->work, vhost_vq_poll_start_work);
> + vhost_vq_work_queue(vq, &vq->work);
> + return 0;
> +}
> +
I wonder whether or not it's better to allow the device to specific the
worker here instead of forcing a per vq worker model. Then we can keep
the behavior of exist implementation and do optimization on top?
Thanks
On Sun, Nov 4, 2018 at 9:53 PM Jason Wang <[email protected]> wrote:
> I wonder whether or not it's better to allow the device to specific the
> worker here instead of forcing a per vq worker model. Then we can keep
> the behavior of exist implementation and do optimization on top?
I was thinking about that too, but for the sake of simplicity it
sounds valid that if the user wanted 8 parallel queues for the disk,
they better be parallel, i.e. worker per queue. The rest of disks that
don't need high-performance, can have 1 queue specified.
--
wbr, Vitaly
On 2018/11/5 上午11:28, Vitaly Mayatskih wrote:
> On Sun, Nov 4, 2018 at 9:53 PM Jason Wang <[email protected]> wrote:
>
>> I wonder whether or not it's better to allow the device to specific the
>> worker here instead of forcing a per vq worker model. Then we can keep
>> the behavior of exist implementation and do optimization on top?
> I was thinking about that too, but for the sake of simplicity it
> sounds valid that if the user wanted 8 parallel queues for the disk,
> they better be parallel, i.e. worker per queue. The rest of disks that
> don't need high-performance, can have 1 queue specified.
>
If you allow device to specify the worker itself, you can do any kinds
of mapping bettween work and worker kthread I think. The advantage of
doing this is that you can keep the vhost-net untouched. This makes
things a little bit easier and proving two kthreads is better than one
for -net workload is probably not as easy as it looks. We may get boost
in some cases but degradation for the rest.
Thanks
On Mon, Nov 5, 2018 at 9:49 PM Jason Wang <[email protected]> wrote:
> If you allow device to specify the worker itself, you can do any kinds
> of mapping bettween work and worker kthread I think. The advantage of
> doing this is that you can keep the vhost-net untouched. This makes
> things a little bit easier and proving two kthreads is better than one
> for -net workload is probably not as easy as it looks. We may get boost
> in some cases but degradation for the rest.
Sounds good. 1 worker is created by vhost as today, all the others are
entering from userspace via ioctl.
--
wbr, Vitaly