Thanks for all the work on io_uring!

As we can see from the io_uring_buf_reg definition:

struct io_uring_buf_reg {
 __u64 ring_addr;
 __u32 ring_entries;
 __u16 bgid;
 __u16 pad;
 __u64 resv[3];
 };

bgid (buffer group ID) is only a u16, this means you can register at most 65536 different buffer groups. I feel a u32 would be a more natural choice here, because in the following situation you might run out of buffer groups:

• You have a server managing a very large number of concurrent connections (so 100K+); hence, you cannot use a buffer group for each separate connection
• Many of these connections are slow and only send a few bytes at a time; hence, you want to use incremental buffer consumption to ensure you don't tie up too much memory
• You want to receive each separate request from each connection in a contiguous buffer; hence, you cannot allow a buffer group to be used by multiple connections since then the data will be interleaved

Maybe when you are working with that number of connections you would probably just want a second ring, in that case I can understand why u16 was chosen.

I will admit an even better solution (but probably more complex) would be to somehow lock buffers within a provided buffer ring to only receive from a specific fd, or otherwise somehow make it so the kernel won't continue incrementally writing at a buffer when there is another multishot recv still incrementally consuming that one.