Seems like it'd be a shame to have the polled/async improvements and not include automatic buffer selection. I guess that'll be the Sunday project.
Was thinking that buffers are provided one-off, not permanently. So you'd have to IORING_OP_PROVIDE_BUFFER once for each buffer ahead of time, and then *again* after used by kernel and consumed by userland. Don't see a lot of benefit of permanent in kernel registry.
-
-
But how would that work for tons of connections, where you generally see poll + recv done now? We can't arm tons of recv with PROVIDE_BUFFER, I don't see how that improves the situation, we'd still need X buffers for X connections. What am I missing?
-
Oh. What I mean is that there's several potential *sets* of ready buffers (identified by a new union member alongside buffer_index). A RECVMSG etc specifies the set to use (buffer_index = registered_buffer = 17). If no buffer in set once ready, signal EBUSY.
- 11 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.