hello, I raised this issue last year and have had some discussions with Pavel, but didn't come to an agreement and didn't come up with better solution. You can see my initial patch and discussions in below mail: https://lore.kernel.org/all/20211012084811.29714-1-xiaoguang.wang@xxxxxxxxxxxxxxxxx/T/ The most biggest issue with file registration feature is that it needs user space apps to maintain free slot info about io_uring's fixed file table, which really is a burden. Now I see io_uring starts to return file slot from kernel by using IORING_FILE_INDEX_ALLOC flag in accept or open operations, but they need app to uses direct accept or direct open, which is not convenient. As far as I know, some apps are not prepared to use direct accept or open: 1) App uses one io_uring instance to accept one connection, but later it will route this new connection to another io_uring instance to complete read/write, which achieves load balance. In this case, direct accept won't work. We still need a valid fd, then another io_uring instance can register it again. 2) After getting a new connection, if later apps wants to call fcntl(2) or setsockopt or similar on it, we will need a true fd, not a flle slot in io_uring's file table, unless we can make io_uring support all existing syscalls which use fd. So we may still need to make io_uring file registration feature easier to use. I'd like io_uring in kernel returns prepared file slot. For example, for IORING_OP_FILES_UPDATE, we support user passes one fd and returns found free slot in cqe->res, just like what IORING_FILE_INDEX_ALLOC does. This is my current rough idea, any more thoughts? Thanks. Regards, Xiaoguang Wang
