Verified Commit a0ff8919 authored by 4lDO2's avatar 4lDO2 🖖
Browse files

Fix typos.

parent 7a55043a
......@@ -6,14 +6,14 @@
# Summary
[summary]: #summary
An low-overhead high-performance asynchronous I/O API, inspired by Linux's `io_uring` (since 5.1). In essence `io_uring` behaves like a regular SPSC channel or queue: the producer pushes entries, which the consumer pops. This interface provides two different rings for each `io_uring` instance, namely the _submission queue_ (SQ) and the _completion queue_ (CQ). The process making the syscall (which from now on is referred to as the _consumer_), sends a _submission queue entry_ (SQE or SE), which the process (or kernel) processing the syscall (referred to as the _producer_) handles, and then sends a _completion queue entry_ (CQE or CE).
A low-overhead high-performance asynchronous I/O API, inspired by Linux's `io_uring` (since 5.1). In essence `io_uring` behaves like a regular SPSC channel or queue: the producer pushes entries, which the consumer pops. This interface provides two different rings for each `io_uring` instance, namely the _submission queue_ (SQ) and the _completion queue_ (CQ). The process making the syscall (which from now on is referred to as the _consumer_), sends a _submission queue entry_ (SQE or SE), which the process (or kernel) processing the syscall (referred to as the _producer_) handles, and then sends a _completion queue entry_ (CQE or CE).
# Motivation
[motivation]: #motivation
Since Redox is a microkernel, context switches will be much more frequent than on monolithic kernels, which do a more miscellaneous work in the kernel. This context switch overhead is even greater when using KPTI to mitigate the recent Meltdown vulnerability; this is also the motivation behind Linux's io_uring API, even if Redox would benefit to a greater extent. By using two separate queues, the _submission queue_, and the _completion queue_, the only overhead whatsoever of the syscall, is to increment two atomic variables (where the second is optional and only for process notification, albeit highly recommended), and write the submission queue entry to a flat shared memory region. Similarly, when a command completes, all that has to be done is the same: incrementing two counters and reading from shared memory. Since the channels are lock-free unless the queues are empty (when receiving) or full (when sending), this also allows two processes that run in parallel to serve each other's requests simultaneously in real-time by polling the rings.
Another reason why `io_uring` is to be considered, is due to the completion-based model for async I/O. While the readiness-based model works greatly for network drivers, where events are triggered by hardware (or rather, polled by the driver), on other hardware such as NVME disks, the hardware will not read from the disk by itself, but has to be started by the driver. The way `xhcid` handles this is by having two files allocated for each hardware endpoint: `ctl` and `data`. Not only is it much more complex and complicated both on for the driver and the driver user, but it also requires two separate syscalls, and thus causes more context switches than it needed to.
Another reason why `io_uring` is to be considered, is due to the completion-based model for async I/O. While the readiness-based model works greatly for network drivers, where events are triggered by hardware (or rather, polled by the driver), on other hardware such as NVME disks, the hardware will not read from the disk by itself, but has to be started by the driver. The way `xhcid` handles this is by having two files allocated for each hardware endpoint: `ctl` and `data`. Not only is it much more complex and complicated both on for the driver and the driver user, but it also requires two separate syscalls, and thus causes more context switches than it needs to.
# Detailed design
[design]: #detailed-design
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment