Linux io_uring multishot accept怎样持续接收连接事件

Linux io_uring 的 multishot accept 不是“把普通 accept 循环写得更快”，而是让一个 accept 请求在仍有效时连续产生多个完成事件。准备阶段调用 io_uring_prep_multishot_accept()，每次连接到达就从 CQE 的 res 取出新 socket fd；真正决定能否继续复用原请求的是 IORING_CQE_F_MORE。如果这个标志消失，就要按终止事件处理，并在需要继续监听时重新提交 accept。

普通 accept、multishot accept 和 direct 该怎么选

三者的核心差异不是监听 socket，而是“一个 SQE 对应几个连接结果”和“新连接放在哪里”。普通 io_uring_prep_accept() 完成一次就结束，下一次连接需要新的 SQE；io_uring_prep_multishot_accept() 提交一次后可以连续得到多个 CQE；io_uring_prep_multishot_accept_direct() 进一步把每个连接放入 fixed file table，并返回动态分配的表索引。

如果应用要兼容不支持该能力的内核，先保留普通 accept 路径更稳妥。multishot 的价值主要在于少维护一份“完成后立刻再提交 accept”的代码；它不会替你处理新连接的协议握手、限流、fd 上限或业务连接生命周期。

一次提交 multishot accept 的关键写法

下面示例只展示监听请求和 CQE 处理骨架。user_data 用稳定值标识监听请求，成功得到的 fd 交给连接处理逻辑；示例没有传入 addr 和 addrlen，因为 multishot 反复复用同一块地址存储时，后来的连接可能覆盖之前尚未处理的数据。

#include 
#include 
#include 
#include 

enum { ACCEPT_UD = 1 };

static int arm_accept(struct io_uring *ring, int listen_fd) {
    struct io_uring_sqe *sqe = io_uring_get_sqe(ring);
    if (sqe == NULL) {
        return -ENOSPC; // SQE 不足时由上层决定何时重试。
    }
    io_uring_prep_multishot_accept(sqe, listen_fd, NULL, NULL, 0);
    io_uring_sqe_set_data64(sqe, ACCEPT_UD); // 让完成循环识别这是监听请求。
    return 0;
}

static void handle_cqe(struct io_uring *ring, struct io_uring_cqe *cqe,
                       int listen_fd) {
    const unsigned flags = cqe->flags;
    const int more = (flags & IORING_CQE_F_MORE) != 0;

    if (cqe->res res; // io_uring 直接返回负 errno，不读取 errno。
        fprintf(stderr, "accept CQE error: %d\n", err);
        io_uring_cqe_seen(ring, cqe);
        arm_accept(ring, listen_fd); // 生产代码还应按错误类型退避或退出。
        return;
    }

    int client_fd = cqe->res; // 非 direct 变体返回新连接的进程 fd。
    process_client(client_fd); // 业务代码负责限流、读写和最终 close(client_fd)。
    io_uring_cqe_seen(ring, cqe);

    if (!more) {
        arm_accept(ring, listen_fd); // 原请求已终止，监听仍需继续时重新 arm。
    }
}

示例中的 process_client 是业务层占位函数，不能把它理解为已经完成了网络读写。若 cqe->res 为负数，错误已经编码在结果里；若结果为正数，仍要在交给业务层后明确谁负责关闭该 fd。

CQE 处理循环要同时看 res 和 flags

判断 multishot 是否持续，不能只看“这次 accept 成功没有”。成功只说明当前连接拿到了 fd；IORING_CQE_F_MORE 才说明后续 CQE 还会由同一个请求产生。没有 MORE 时，当前 CQE 仍然要消费，但原请求已经结束，监听服务若要继续接收就必须重新 arm。

对退出流程也要保留同一判断：先提交针对 user_data 的取消请求，再消费取消请求 CQE 和 multishot 的最终 CQE。最终 CQE 通常带 -ECANCELED，且不会再带 MORE。不要在看到取消请求完成后立刻销毁 ring，仍需按你的退出协议收完相关 CQE。

direct 变体、兼容性和资源边界

io_uring_prep_multishot_accept_direct() 适合已经使用 registered file table 的服务。动态分配槽位时，每个成功 CQE 返回的是表索引；表没有空闲项会得到 -ENFILE，这不是客户端协议错误，而是资源策略需要处理的信号。没有 fixed file table 管理需求时，普通 multishot 反而更容易维护。

multishot accept 的接口能力从 Linux 5.19 起可用，但部署不能只看开发机内核：启动时可以用能力探测或一次小请求确认，并保留普通 accept fallback。内核不认识该请求、SQE 获取失败、监听 fd 被关闭、进程 fd 或 fixed file table 达到上限，都应进入可观测的退化路径，而不是无条件忙循环 re-arm。

常见问题

multishot accept 还需要每次提交 SQE 吗？

在请求仍带 IORING_CQE_F_MORE 时不需要；当 MORE 消失或请求因错误结束时，如果监听服务仍要工作，就要重新准备并提交 accept。

为什么成功的 accept 也不能跳过 flags 检查？

因为 cqe->res 只描述当前连接结果，flags 描述原 multishot 请求的后续生命周期。忽略 flags 会让服务在请求已终止后误以为它仍会产生事件。

什么时候直接使用 direct multishot？

只有在服务已经围绕 registered file table 设计了槽位、回收和并发访问策略时才值得使用；否则先采用普通 multishot，问题边界更小。