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
signature.asc
Description: PGP signature
