Closed puzpuzpuz closed 1 year ago
I’m happy to benchmark this if we have a matching Node PR. It’s very interesting!
@mcollina no, we don't have a Node.js counterpart PR yet. But I hope to submit one once I find out status of the libuv PR. Will post any updates here.
There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.
For more information on how the project manages feature requests, please consult the feature request management document.
There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.
For more information on how the project manages feature requests, please consult the feature request management document.
I was hoping to answer this issue with a PR, but unfortunately time has been lacking. The removal of QUIC was a disruption for some of my services, so I decided to reimplement it with IO_URING
and WASM, via quinn_proto, to enable a faster implementation compared to a native NAPI
approach. Unfortunately that code is owned by my previous employer, but I took a sabbatical year from work and I'm building a clean room implementation for my next gen database.
Some suggestions, coming from my personal experience:
I found implementing IO_URING
via NAPI
or libuv
too difficult, instead I decided to take a different approach, by enabling syscalls via NAPI
. You can then write a WASM module that setup io_uring
and interact with it using shared memory. Once io_uring
is setup you can use it for anything you want (network, disk IO, asynchronous crypto or DNS, ...)
This way you're not only extremely simplifying your work, but you are enabling code reuse across several WASM implementations (Node, Deno, ....). This approach marks almost a philosophical departure from the current Node.js monolithic architecture, in the sense that it looks a lot like a micro kernel with loaded modules.
I think this could be of interest for #44325. CC: @mcollina @jasnell
For the future engineer who will have to implement this, I created awesome io_uring
as a collection of articles, tutorials, libraries and examples to help implement this interface.
There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.
For more information on how the project manages feature requests, please consult the feature request management document.
I'm going to close this because it's not actionable for node. io_uring support will likely come to libuv soon (I'm working on it) but it will be a transparent change to node.
io_uring support has been merged into node libuv!!! Thanks @bnoordhuis for your work
@espoal it was not merged into node.js just yet I guess. We'll need to wait for a libuv update here.
@mcollina yes you're right :) Is there anything I can do to help with the process of integrating io_uring?
Once there is a new release of libuv, this will be updated
https://github.com/libuv/libuv/releases/tag/v1.45.0 New version released! Hope we will get nodejs support soon.
Node v20 released with libuv 1.46 if I'm not mistaken, will we see support in v21?
@bnoordhuis The commentary around this functionality in libuv implies that libuv users will need to rework their code to take full advantage of the io_uring support. So unless I'm reading that wrong, "there's nothing for us to do" is not correct. You might get some benefit without doing anything, but there's more to be had.
Recent Linux kernel (5.1+) includes io_uring, a new non-blocking I/O subsystem, which might serve as a more efficient alternative to epoll. We could benefit from it and get a performance improvement in network I/O scenarios with high volume of concurrent connections and/or for fs operations.
Of course, in Node.js case we need changes made in libuv. There is an ongoing experiment aimed to add support for io_uring in libuv: https://github.com/libuv/libuv/pull/2322
As this feature should be experimental (at least initially), io_uring mode could be activated under a new flag.
The goal of this issue is to improve visibility of the libuv experiment and gather some feedback.