The reason why I say this is that it means that instead of doing poll syscall, then get event, then issue new syscall, you can simply issue the recv. As data becomes available, it's consumed as soon as the app runs. No extra round trips, no thread offload. Win/win Now 4x faster!https://twitter.com/axboe/status/1229486613857591296 …
-
-
I wrote about that the other day, but tldr is that I think we can do something cool there with bpf and buffer selection. If none are free, then defer.
-
Cool! On io-uring@vger? Or twitter?
- 3 more replies
New conversation -
-
-
Perhaps something like a IOSQE_INTO_REGISTERED_BUFFER + cqe->res as an index into the array of registered buffers? With a iov or such indicating length of data? Seems pretty crummy :(
-
I think we need some programmable logic for it instead of overloading cqe->res.
- 2 more replies
New conversation -
-
-
Have the same issue; can have 500k+ client connections. Now per-worker-thread pools of read objects too.
-
I think just doing uring polls for readiness, and then batching the submission of recvs, works actually pretty well once you're at that scale. More often than not there'll be multiple POLLs finishing at a time, allowing to submit multiple recvs too. Still overhead obviously.
- 2 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.