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 @axboe
Once userspace is done with a buffer used by RECVMSG, it can free the memory, or provide it again to the kernel for the set of buffers. Multiple sets because different recvmsgs might need differently sized buffers.
1 reply 0 retweets 0 likes
E.g. the sockets waiting for a new 'command' from client wouldn't want a large buffer, but sockets waiting for a bulk file upload would.
-
-
Replying to @AndresFreundTec
Totally untested, but see below for the direction. What do you think? https://git.kernel.dk/cgit/linux-block/log/?h=io_uring-buf-select …
1 reply 0 retweets 1 like -
Replying to @axboe
Looks good on a first read. Probably need to limit buffer ids to something < 32bit? Should the kernel check for non-uniqueness of ids?
1 reply 0 retweets 0 likes - 7 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.