[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200713092435.GC28639@stefanha-x1.localdomain>
Date: Mon, 13 Jul 2020 10:24:35 +0100
From: Stefan Hajnoczi <stefanha@...hat.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Cc: Jens Axboe <axboe@...nel.dk>, Sargun Dhillon <sargun@...gun.me>,
Kees Cook <keescook@...omium.org>, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org,
Kernel Hardening <kernel-hardening@...ts.openwall.com>,
Jann Horn <jannh@...gle.com>, Aleksa Sarai <asarai@...e.de>,
Christian Brauner <christian.brauner@...ntu.com>,
io-uring@...r.kernel.org, Alexander Viro <viro@...iv.linux.org.uk>,
Jeff Moyer <jmoyer@...hat.com>,
Stefano Garzarella <sgarzare@...hat.com>
Subject: Re: [PATCH RFC 0/3] io_uring: add restrictions to support untrusted
applications and guests
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
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
