archive mirror
 help / color / mirror / Atom feed
From: Jens Axboe <>
Subject: [PATCHSET RFC 0/5] file_operations based io_uring commands
Date: Wed, 27 Jan 2021 14:25:36 -0700	[thread overview]
Message-ID: <> (raw)


This is a concept I've been toying with, some (including myself) have
referred to it as a way to do ioctls over io_uring. And indeed it has
many similarities with that. The purpose of the patchset is to have
a file private command type. io_uring doesn't know or care what is in
it, only the end target would be able to do that. In that sense it's
similar to ioctls which share the same trait. io_uring just provides
all the infrastructure to pass them back and forth, etc.

At the core of it, we overlay a struct type on top of io_uring_sqe.
That's basically like other commands, except this one is a bit more
brutal. That leaves us with 32 bytes that we can use, 8 bytes that
we can't (as they overlap with ->user_data), and then 8 bytes that are
usable again. Hence there's 40 bytes available for a command, anything
more than that should be allocated as per usual for request types.

The file_operations structure is augmented to add a ->uring_cmd()
handler. A file type must support this operation to support these
kinds of commands, otherwise they get errored. This handler can
either queue this operation async and signal completion when done,
or it can complete it inline (either successfully, or in error).

Proof of concept added for raw block and network commands, just to
show how it could work. Nothing exciting/interesting yet, just a
way to test it out.

This is very much sent out for comments/review of the concept itself.
There are a host of things that could be implemented with this, like
raw device access, new APIs (network zero copy additions), etc.

I'm not a huge fan of the command overlay, but I do like the fact that
we can do alloc less commands as long as we stay at <= 40 bytes. So
maybe it's just a pill that we have to swallow. Or maybe there are
other great ideas for how to do this. It does mean that we overlay
much of the sqe, but most of that won't make sense for private commands.

Anyways, comments welcome. This is kept on io_uring for now until
details have been hashed out.

Jens Axboe

             reply	other threads:[~2021-01-27 21:27 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-27 21:25 Jens Axboe [this message]
2021-01-27 21:25 ` [PATCH 1/5] fs: add file_operations->uring_cmd() Jens Axboe
2021-01-27 21:25 ` [PATCH 2/5] io_uring: add support for IORING_OP_URING_CMD Jens Axboe
2021-01-28  0:38   ` Darrick J. Wong
2021-01-28  1:45     ` Jens Axboe
2021-01-28  2:19       ` Jens Axboe
2021-02-20  3:57         ` Stefan Metzmacher
2021-02-20 14:50           ` Jens Axboe
2021-02-20 16:45             ` Jens Axboe
2021-02-22 20:04               ` Stefan Metzmacher
2021-02-22 20:14                 ` Jens Axboe
2021-02-23  8:14                   ` Stefan Metzmacher
2021-02-23 13:21                     ` Pavel Begunkov
2021-01-27 21:25 ` [PATCH 3/5] block: wire up support for file_operations->uring_cmd() Jens Axboe
2021-01-27 21:25 ` [PATCH 4/5] block: add example ioctl Jens Axboe
2021-01-27 21:25 ` [PATCH 5/5] net: wire up support for file_operations->uring_cmd() 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:

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

  git send-email \ \ \ \

* 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).