On Fri, Jul 10, 2020 at 06:20:17PM +0200, Stefano Garzarella wrote: > On Fri, Jul 10, 2020 at 11:33:09AM -0400, Konrad Rzeszutek Wilk wrote: > > .snip.. > > > Just to recap the proposal, the idea is to add some restrictions to the > > > operations (sqe, register, fixed file) to safely allow untrusted applications > > > or guests to use io_uring queues. > > > > Hi! > > > > This is neat and quite cool - but one thing that keeps nagging me is > > what how much overhead does this cut from the existing setup when you use > > virtio (with guests obviously)? > > I need to do more tests, but the preliminary results that I reported on > the original proposal [1] show an overhead of ~ 4.17 uS (with iodepth=1) > when I'm using virtio ring processed in a dedicated iothread: > > - 73 kIOPS using virtio-blk + QEMU iothread + io_uring backend > - 104 kIOPS using io_uring passthrough > > > That is from a high level view the > > beaty of io_uring being passed in the guest is you don't have the > > virtio ring -> io_uring processing, right? > > Right, and potentially we can share the io_uring queues directly to the > guest userspace applications, cutting down the cost of Linux block > layer in the guest. Another factor is that the guest submits requests directly to the host kernel sqpoll thread. When a virtqueue is used the sqpoll thread cannot poll it directly so another host thread (QEMU) needs to poll the virtqueue. The same applies for the completion code path. Stefan
Attachment:
signature.asc
Description: PGP signature
