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.
-
-
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 -
Replying to @AndresFreundTec @axboe
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.
1 reply 0 retweets 2 likes -
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 -
Replying to @AndresFreundTec
Pushed update, now it works. No error checking is done yet, for length of buffer, group id, etc. So that needs doing, this is just provided for direction. I thought about the buffer id, and I think that's just up to the application. But I'm open to improvements.
1 reply 0 retweets 0 likes -
Replying to @axboe
Mostly commented on the buffer ids width bit because it's ABI. Wondering whether cqe.flags ought to be split into two parts. Perhaps that'd still be ok because there's no uses of it yet?
1 reply 0 retweets 0 likes -
Replying to @AndresFreundTec
Not close enough to worry about ABI yet ;-) We could split the flags, it is indeed unused. But 2G buffer IDs is probably enough? And leaves us free to use the flags in the future as well.
1 reply 0 retweets 0 likes -
Replying to @axboe
For future extensibility it seems like it'd be good to have space for additional cqe flags that can be specified concurrently with IORING_CQE_F_BUFFER, Which'd be harder if 31 bit buffer ids were allowed initially. Hence wondering about a more explicit split of flag & "tag".
1 reply 0 retweets 1 like -
Replying to @AndresFreundTec
We can shrink it for sure, wondering how many buffers we actually need...
1 reply 0 retweets 0 likes
Hard to see a need for more than 16bits. Userland can extend by using more buffer groups, if necessary.
-
-
Thanks. 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.