linux-block.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Roman Penyaev <rpenyaev@suse.de>
To: Ilya Dryomov <idryomov@gmail.com>
Cc: Jens Axboe <axboe@kernel.dk>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	linux-aio@kvack.org, linux-block <linux-block@vger.kernel.org>,
	linux-arch@vger.kernel.org, Christoph Hellwig <hch@lst.de>,
	jmoyer@redhat.com, avi@scylladb.com,
	linux-block-owner@vger.kernel.org
Subject: Re: [PATCHSET v2] io_uring IO interface
Date: Fri, 11 Jan 2019 17:39:33 +0100	[thread overview]
Message-ID: <43189f1be5f03697f750631d31ffaed5@suse.de> (raw)
In-Reply-To: <CAOi1vP9B7Z5jm4vcLux8eOvixgWmC7V=zKBzGnOOJHYO1AhVwA@mail.gmail.com>

On 2019-01-11 17:11, Ilya Dryomov wrote:
> On Fri, Jan 11, 2019 at 10:51 AM Roman Penyaev <rpenyaev@suse.de> 
> wrote:
>> 
>> Hi Jens,
>> 
>> That is interesting.  Recently I sent an rfc related to epoll uring:
>> 
>> https://lore.kernel.org/lkml/20190109164025.24554-1-rpenyaev@suse.de
>> 
>> which can be mapped to userspace and all ready events can be consumed
>> from it directly.  I am wondering, is it possible to make some common
>> API for all kind of ready events / urings, or it doesn't make any
>> sense?
> 
> I think you can use the new IOCB_CMD_POLL from Christoph and avoid
> epoll_wait() in favor of aio/io_uring interface, at least in new high
> performance applications.

Yeah, I saw this extension for aio from Christoph.  I was motivated to
extend epoll with uring to avoid constant recharging of file 
descriptors,
i.e. once you inserted descriptor to epoll you just consume events from
uring (of course in that particular case only edge triggered events are
supported).

Also recently for epoll I fixed contention on event callback making hot
path completely lockless, i.e. with uring epoll can become a nice thingy
in terms of performance.

But can any descriptor (on vfs layer) be extended to have a uring? To 
have
some common API? Then if event source (say socket) has a uring (do not
know how, just thoughts) and event destination (aio, epoll) has a uring,
then reading on userside can be a matter of traversing urings.

> Reaping events entirely in userspace (i.e.
> performing io_getevents() without entering the kernel) has been
> possible for a long time even with the existing aio interface.

True.

--
Roman

  parent reply	other threads:[~2019-01-11 16:39 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-10  2:43 [PATCHSET v2] io_uring IO interface Jens Axboe
2019-01-10  2:43 ` [PATCH 01/15] fs: add an iopoll method to struct file_operations Jens Axboe
2019-01-10  2:43 ` [PATCH 02/15] block: wire up block device iopoll method Jens Axboe
2019-01-10  2:43 ` [PATCH 03/15] block: add bio_set_polled() helper Jens Axboe
2019-01-10  2:43 ` [PATCH 04/15] iomap: wire up the iopoll method Jens Axboe
2019-01-10  2:43 ` [PATCH 05/15] Add io_uring IO interface Jens Axboe
2019-01-11 18:19   ` Martin K. Petersen
2019-01-11 18:34     ` Jens Axboe
2019-01-13 16:22       ` Jens Axboe
2019-01-15 17:31         ` Martin K. Petersen
2019-01-10  2:43 ` [PATCH 06/15] io_uring: support for IO polling Jens Axboe
2019-01-10  2:43 ` [PATCH 07/15] io_uring: add submission side request cache Jens Axboe
2019-01-10  2:43 ` [PATCH 08/15] fs: add fget_many() and fput_many() Jens Axboe
2019-01-10  2:43 ` [PATCH 09/15] io_uring: use fget/fput_many() for file references Jens Axboe
2019-01-10  2:43 ` [PATCH 10/15] io_uring: batch io_kiocb allocation Jens Axboe
2019-01-10  2:44 ` [PATCH 11/15] block: implement bio helper to add iter bvec pages to bio Jens Axboe
2019-01-10  2:44 ` [PATCH 12/15] io_uring: add support for pre-mapped user IO buffers Jens Axboe
2019-01-10  2:44 ` [PATCH 13/15] io_uring: support kernel side submission Jens Axboe
2019-01-10  2:44 ` [PATCH 14/15] io_uring: add submission polling Jens Axboe
2019-01-10  2:44 ` [PATCH 15/15] io_uring: add io_uring_event cache hit information Jens Axboe
2019-01-10 23:12   ` Jeff Moyer
2019-01-10 23:47     ` Jens Axboe
2019-01-11  9:46 ` [PATCHSET v2] io_uring IO interface Roman Penyaev
2019-01-11 16:11   ` Ilya Dryomov
2019-01-11 16:21     ` Christoph Hellwig
2019-01-11 16:39     ` Roman Penyaev [this message]
2019-01-11 18:05   ` Jens Axboe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43189f1be5f03697f750631d31ffaed5@suse.de \
    --to=rpenyaev@suse.de \
    --cc=avi@scylladb.com \
    --cc=axboe@kernel.dk \
    --cc=hch@lst.de \
    --cc=idryomov@gmail.com \
    --cc=jmoyer@redhat.com \
    --cc=linux-aio@kvack.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-block-owner@vger.kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).