> From: Stefan Hajnoczi <stefa...@redhat.com> > > Introduce a thread pool so that fv_queue_thread() just pops > VuVirtqElements and hands them to the thread pool. For the time being > only one worker thread is allowed since passthrough_ll.c is not > thread-safe yet. Future patches will lift this restriction so that > multiple FUSE requests can be processed in parallel. > > The main new concept is struct FVRequest, which contains both > VuVirtqElement and struct fuse_chan. We now have fv_VuDev for a device, > fv_QueueInfo for a virtqueue, and FVRequest for a request. Some of > fv_QueueInfo's fields are moved into FVRequest because they are > per-request. The name FVRequest conforms to QEMU coding style and I > expect the struct fv_* types will be renamed in a future refactoring. > > This patch series is not optimal. fbuf reuse is dropped so each request > does malloc(se->bufsize), but there is no clean and cheap way to keep > this with a thread pool. The vq_lock mutex is held for longer than > necessary, especially during the eventfd_write() syscall. Performance > can be improved in the future. > > prctl(2) had to be added to the seccomp whitelist because glib invokes > it. > > Signed-off-by: Stefan Hajnoczi <stefa...@redhat.com>
Looks good to me. Reviewed-by: Misono Tomohiro <misono.tomoh...@jp.fujitsu.com>
