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.
-
-
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 -
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
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".
-
-
Replying to @AndresFreundTec
We can shrink it for sure, wondering how many buffers we actually need...
1 reply 0 retweets 0 likes -
Replying to @axboe
Hard to see a need for more than 16bits. Userland can extend by using more buffer groups, if necessary.
1 reply 0 retweets 0 likes - 1 more reply
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.