5 ms·

They mention working on using io_uring for filesystem calls for 2021. I wonder if there will be an option to use io_uring (instead of epoll) for networking call

by seeekr 6y ago

They mention working on using io_uring for filesystem calls for 2021. I wonder if there will be an option to use io_uring (instead of epoll) for networking calls as well? Handling network packets and events completely in userspace should allow for lower latency due to no more context switches to and from the Kernel, right?

carllerche 6y ago
We are definitely exploring this as well. There are a few possible ways to move forward on this. I'm not sure which is best yet, but with 1.0 out, we are going to be able to put more time into it.
gaogao 6y ago
There's some interesting bits on the low-level work for using io_uring with the Ringbahn crate - https://boats.gitlab.io/blog/post/ringbahn/ https://boats.gitlab.io/blog/post/ringbahn/
- Smerity 6y ago
  The author of sled[1], an embedded database in Rust which has a number of promising features, has also written parts of rio[2], an underlying pure Rust io_uring library, which is intended to become the core write path for sled. rio has support for files but also has a demo for TCP (on Linux 5.5 and later) and O_DIRECT. I tested rio recently as I had a Brilliant but Bad Idea™ involving file access and was pleasantly surprised by the API, as I have been with sled's. I'm excited for the experimentation in the Rust ecosystem and for such low level crates to handle the complex io_uring tasks (relatively) safely! [1]: https://github.com/spacejam/sled https://github.com/spacejam/sled [2]: https://github.com/spacejam/rio https://github.com/spacejam/rio
pas 6y ago
Both epoll and io_uring depend on the kernel to do the "actual IO", if you want really user-space you need DPDK and a userspace network stack (for TCP/UDP). Both epoll and io_uring have virtually the same performance. Of course uring is a lot more "ergonomic" that's why it already has amazing momentum.
- anarazel 6y ago
  You can do network IO completion notification, instead of readiness notification with io_uring but not epoll. Which avoids the need for a separate syscall that needs to copy memory into the userspace buffers. That can be noticable. It should also, at some point, allow for nice zero copy network receive paths under the right circumstances (i.e. the network card DMAing directly into the userspace buffers, without very weird setup/high op overhead).

by seeekr 6y ago

carllerche 6y ago

We are definitely exploring this as well. There are a few possible ways to move forward on this. I'm not sure which is best yet, but with 1.0 out, we are going to be able to put more time into it.

gaogao 6y ago

There's some interesting bits on the low-level work for using io_uring with the Ringbahn crate - https://boats.gitlab.io/blog/post/ringbahn/ https://boats.gitlab.io/blog/post/ringbahn/

Smerity 6y ago
The author of sled[1], an embedded database in Rust which has a number of promising features, has also written parts of rio[2], an underlying pure Rust io_uring library, which is intended to become the core write path for sled. rio has support for files but also has a demo for TCP (on Linux 5.5 and later) and O_DIRECT. I tested rio recently as I had a Brilliant but Bad Idea™ involving file access and was pleasantly surprised by the API, as I have been with sled's. I'm excited for the experimentation in the Rust ecosystem and for such low level crates to handle the complex io_uring tasks (relatively) safely! [1]: https://github.com/spacejam/sled https://github.com/spacejam/sled [2]: https://github.com/spacejam/rio https://github.com/spacejam/rio

pas 6y ago

Both epoll and io_uring depend on the kernel to do the "actual IO", if you want really user-space you need DPDK and a userspace network stack (for TCP/UDP). Both epoll and io_uring have virtually the same performance. Of course uring is a lot more "ergonomic" that's why it already has amazing momentum.

anarazel 6y ago
You can do network IO completion notification, instead of readiness notification with io_uring but not epoll. Which avoids the need for a separate syscall that needs to copy memory into the userspace buffers. That can be noticable. It should also, at some point, allow for nice zero copy network receive paths under the right circumstances (i.e. the network card DMAing directly into the userspace buffers, without very weird setup/high op overhead).