search for: use_work

vDPA device currently relays the eventfd via vhost worker. This is inefficient due the latency of wakeup and scheduling, so this patch tries to introduce a use_worker attribute for the vhost device. When use_worker is not set with vhost_dev_init(), vhost won't try to allocate a worker thread and the vhost_poll will be processed directly in the wakeup function. This help for vDPA since it reduces the latency caused by vhost worker. In my testing, it saves...

...er); } +static void vhost_vq_detach_worker(struct vhost_virtqueue *vq) +{ + if (vq->worker) + vhost_worker_put(vq->dev, vq->worker); + vq->worker = NULL; +} + +static void vhost_workers_free(struct vhost_dev *dev) +{ + struct vhost_worker *worker; + unsigned long i; + + if (!dev->use_worker) + return; + + for (i = 0; i < dev->nvqs; i++) + vhost_vq_detach_worker(dev->vqs[i]); + /* + * Drop the refcount taken during allocation, and handle the default + * worker and the cases where userspace might have crashed or was lazy + * and did a VHOST_NEW_WORKER but not a VHOST_FRE...

Hi all: This series introduce basic functionality of doorbell mapping support for vhost-vDPA. Userspace program may use mmap() to map a the doorbell of a specific virtqueue into its address space. This is help to reudce the syscall or vmexit overhead. A new vdpa_config_ops was introduced to report the location of the doorbell, vhost_vdpa may then choose to map the doorbell when: - The doorbell

Hi all: This series introduce basic functionality of doorbell mapping support for vhost-vDPA. Userspace program may use mmap() to map a the doorbell of a specific virtqueue into its address space. This is help to reudce the syscall or vmexit overhead. A new vdpa_config_ops was introduced to report the location of the doorbell, vhost_vdpa may then choose to map the doorbell when: - The doorbell

...pin this address space for an >> * unbounded/indefinite amount of time. > >I wonder if everything would be simplified if we just allow the parent >to advertise whether or not it requires the address space. > >Then when vhost-vDPA probes the device it can simply advertise >use_work as true so vhost core can use get_task_mm() in this case? IIUC set user_worker to true, it also creates the kthread in the vhost core (but we can add another variable to avoid this). My biggest concern is the comment in include/linux/sched/mm.h. get_task_mm() uses mmget(), but in the documentatio...

...void *key) > { > struct vhost_poll *poll = container_of(wait, struct vhost_poll, wait); > + struct vhost_work *work = &poll->work; > > if (!(key_to_poll(key) & poll->mask)) > return 0; > > - vhost_poll_queue(poll); > + if (!poll->dev->use_worker) > + work->fn(work); > + else > + vhost_poll_queue(poll); > + > return 0; > } > So a wakeup function wakes up eventfd directly. What if user supplies e.g. the same eventfd as ioeventfd? Won't this cause infinite loops? -- MST

...ting the codes. How about adding something like in vhost_poll_wakeup(): ??? struct vhost_poll *poll = container_of(wait, struct vhost_poll, wait); ??? struct vhost_work *work = &poll->work; ??? if (!(key_to_poll(key) & poll->mask)) ??? ??? return 0; ??? if (!poll->dev->use_worker) ??? ??? work->fn(work); ??? else ??? ??? vhost_poll_queue(poll); Then modify vhost_dev_init() to set use_worker (all true except for vdpa)? Thanks

...indefinite amount of time. >> > >> >I wonder if everything would be simplified if we just allow the parent >> >to advertise whether or not it requires the address space. >> > >> >Then when vhost-vDPA probes the device it can simply advertise >> >use_work as true so vhost core can use get_task_mm() in this case? >> >> IIUC set user_worker to true, it also creates the kthread in the vhost >> core (but we can add another variable to avoid this). >> >> My biggest concern is the comment in include/linux/sched/mm.h. >>...

...* Never use this function to pin this address space for an > * unbounded/indefinite amount of time. I wonder if everything would be simplified if we just allow the parent to advertise whether or not it requires the address space. Then when vhost-vDPA probes the device it can simply advertise use_work as true so vhost core can use get_task_mm() in this case? Thanks > > Signed-off-by: Stefano Garzarella <sgarzare at redhat.com> > --- > > Notes: > v3: > - called mmget_not_zero() before kthread_use_mm() [Jason] > As the documentation of mmget() in inclu...

...struct vhost_vring_worker *info) > >> +{ > >> + unsigned long index = info->worker_id; > >> + struct vhost_dev *dev = vq->dev; > >> + struct vhost_worker *worker; > >> + > >> + if (!dev->use_worker) > >> + return -EINVAL; > >> + > >> + /* > >> + * We don't support setting a worker on an active vq to make flushing > >> + * and removal simple. > >> + */ > >> + if (vhost_vq_get_bac...

The following patches were built over linux-next which contains various vhost patches in mst's tree and the vhost_task patchset in Christian Brauner's tree: git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux.git kernel.user_worker branch: https://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux.git/log/?h=kernel.user_worker The latter patchset handles the review comment

Hi All: This series tries to add the support for control virtqueue in vDPA. Control virtqueue is used by networking device for accepting various commands from the driver. It's a must to support multiqueue and other configurations. When used by vhost-vDPA bus driver for VM, the control virtqueue should be shadowed via userspace VMM (Qemu) instead of being assigned directly to Guest. This is

Hi All: This series tries to add the support for control virtqueue in vDPA. Control virtqueue is used by networking device for accepting various commands from the driver. It's a must to support multiqueue and other configurations. When used by vhost-vDPA bus driver for VM, the control virtqueue should be shadowed via userspace VMM (Qemu) instead of being assigned directly to Guest. This is