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.
-
Show this thread
-
I have this working now, but I'm not sure how best to handle buffer life times. IOW, kernel selects a free buffer, but userspace needs to signal when it can be reused. I'm thinking a specific opcode for that, IORING_OP_BUFFER_FREE or something. Taking suggestions and/or advice!
1 reply 1 retweet 1 likeShow this thread -
I kind of like the opcode idea, as let's say you do a recv() and a buffer is selected. Presumably you're going to use that for a send or write, and you could link the IORING_OP_BUFFER_FREE command after that.
2 replies 0 retweets 1 likeShow this thread -
Replying to @axboe
IORING_OP_BUFFER_FREE suggests that buffers are registered somehow (?). How about instead having an explicit opcode that provides a buffer for a one-off use? A IORING_OP_PROVIDE_BUFFER registers a buffer as available, with buf_index (under different name) indicating a 'group'.
2 replies 0 retweets 0 likes -
Replying to @AndresFreundTec
Question is where that buffer comes from, my current code is having the app provide them (upfront). Kernel selects one (for IOSQE_BUFFER_SELECT), and IORING_OP_BUFFER_FREE marks that buffer as free again.
1 reply 0 retweets 0 likes -
Replying to @axboe
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.
1 reply 0 retweets 0 likes -
Replying to @AndresFreundTec
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?
1 reply 0 retweets 0 likes -
Replying to @axboe
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.
2 replies 0 retweets 0 likes -
Replying to @AndresFreundTec
Ah ok, that makes more sense then. I kind of like that idea, seems flexible and you can manage connections into sets on the app side, or requests into sets. And the buffer is removed from the set permanently when used in the kernel, app must provide it again, so lifetime handled.
1 reply 0 retweets 1 like -
Replying to @axboe
Precisely. Wondering if FDs for things like chained open();stat();close(); could be handled similarly. Instead of having to write BPF, which explodes the necessary toolchain.
1 reply 0 retweets 0 likes
When IOSQE_TAGED_FILE is set, sqe.fd doesn't refer to an fd, but is just an arbitrary userland specified identifier. OPENAT etcwould associate identifier with fd. READV/WRITEV/CLOSE would look up identifier to get real fd. And EBADF if not set.
-
-
Replying to @AndresFreundTec
That should work, and eliminate the need to carry results from one SQE to the next.
0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
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.