summaryrefslogtreecommitdiffhomepage
path: root/g3doc/proposals/gsoc-2021-ideas.md
diff options
context:
space:
mode:
authorRahat Mahmood <rahat@google.com>2021-02-10 13:04:24 -0800
committergVisor bot <gvisor-bot@google.com>2021-02-10 13:06:42 -0800
commitc2f204658ed4a6b0bd110577f22fbfd4104a6f96 (patch)
treeef767f606acb8029b282c724aeb4c7e247ae4bcd /g3doc/proposals/gsoc-2021-ideas.md
parent458bf12c1360570fc4cf0fd206768393c3d976f5 (diff)
Add proposal for io_uring project.
PiperOrigin-RevId: 356807933
Diffstat (limited to 'g3doc/proposals/gsoc-2021-ideas.md')
-rw-r--r--g3doc/proposals/gsoc-2021-ideas.md71
1 files changed, 71 insertions, 0 deletions
diff --git a/g3doc/proposals/gsoc-2021-ideas.md b/g3doc/proposals/gsoc-2021-ideas.md
new file mode 100644
index 000000000..0c2e2afaa
--- /dev/null
+++ b/g3doc/proposals/gsoc-2021-ideas.md
@@ -0,0 +1,71 @@
+# Project Ideas for Google Summer of Code 2021
+
+This is a collection of project ideas for
+[Google Summer of Code 2021][gsoc-2021-site]. These projects are intended to be
+relatively self-contained and should be good starting projects for new
+contributors to gVisor. We expect individual contributors to be able to make
+reasonable progress on these projects over the course of several weeks.
+Familiarity with Golang and knowledge about systems programming in Linux will be
+helpful.
+
+If you're interested in contributing to gVisor through Google Summer of Code
+2021, but would like to propose your own idea for a project, please see our
+[roadmap](../roadmap.md) for areas of development, and get in touch through our
+[mailing list][gvisor-mailing-list] or [chat][gvisor-chat]!
+
+## Implement `io_uring`
+
+`io_uring` is the lastest asynchronous I/O API in Linux. This project will
+involve implementing the system interfaces required to support `io_uring` in
+gVisor. A successful implementation should have similar relatively performance
+and scalability characteristics compared to synchronous I/O syscalls, as in
+Linux.
+
+The core of the `io_uring` interface is deceptively simple, involving only three
+new syscalls:
+
+- `io_uring_setup(2)` creates a new `io_uring` instance represented by a file
+ descriptor, including a set of request submission and completion queues
+ backed by shared memory ring buffers.
+
+- `io_uring_register(2)` optionally binds kernel resources such as files and
+ memory buffers to handles, which can then be passed to `io_uring`
+ operations. Pre-registering resources in this way moves the cost of looking
+ up and validating these resources to registration time rather than paying
+ the cost during the operation.
+
+- `io_uring_enter(2)` is the syscall used to submit queued operations and wait
+ for completions. This is the most complex part of the mechanism, requiring
+ the kernel to process queued request from the submission queue, dispatching
+ the appropriate I/O operation based on the request arguments and blocking
+ for the requested number of operations to be completed before returning.
+
+An `io_uring` request is effectively an opcode specifying the I/O operation to
+perform, and corresponding arguments. The opcodes and arguments closely relate
+to the the corresponding synchronous I/O syscall. In addition, there are some
+`io_uring`-specific arguments that specify things like how to process requests,
+how to interpret the arguments and communicate the status of the ring buffers.
+
+For a detailed description of the `io_uring` interface, see the
+[design doc][io-uring-doc] by the `io_uring` authors.
+
+Due to the complexity of the full `io_uring` mechanism and the numerous
+supported operations, it should be implemented in two stages:
+
+In the first stage, a simplified version of the `io_uring_setup` and
+`io_uring_enter` syscalls should be implemented, which will only support a
+minimal set of arguments and just one or two simple opcodes. This simplified
+implementation can be used to figure out how to integreate `io_uring` with
+gVisor's virtual filesystem and memory management subsystems, as well as
+benchmark the implementation to ensure it has the desired performance
+characteristics. The goal in this stage should be to implement the smallest
+subset of features required to perform a basic operation through `io_uring`s.
+
+In the second stage, support can be added for all the I/O operations supported
+by Linux, as well as advanced `io_uring` features such as fixed files and
+buffers (via `io_uring_register`), polled I/O and kernel-side request polling.
+
+[gsoc-2021-site]: https://summerofcode.withgoogle.com
+[gvisor-chat]: https://gitter.im/gvisor/community
+[gvisor-mailing-list]: https://groups.google.com/g/gvisor-dev
+[io-uring-doc]: https://kernel.dk/io_uring.pdf