我的理解--可能是错误的--是一个操作可以处于三种可能的迭代状态之一：
1.在提交队列中等待（表示为提交队列项）
1.运行中（即，内核已从提交队列中删除提交队列条目，但尚未完成IO）。
1.完成
假设有一个应用程序请求数百万次IO操作，它有两个线程和一个具有32个提交队列条目槽的io_uring示例。
一个线程负责保持提交队列满：当应用程序启动时，这个线程用32个条目填充提交队列。然后，当提交队列已满时，它会阻塞。一旦提交队列变为“未满”，它会提交另一个SQE。
另一个线程获取完成队列事件。
此应用程序是否可能使完成队列溢出？
"Efficient IO with io_uring" PDF建议-是的-此应用程序将溢出完成队列：
通常一个应用程序会要求一个给定大小的环，假设这个大小直接对应于应用程序在内核中可以有多少个请求挂起。然而，由于sqe的生存期只是它实际提交的生存期，应用程序有可能驱动比SQ环大小指示的更高的挂起请求计数。因此，否则可能会有溢出CQ环的风险。默认情况下，CQ环的大小是SQ环的两倍。这使应用程序在管理这一方面有一定的灵活性，但并不能完全消除这样做的必要性。如果应用程序违反了此限制，则会在CQ环中将其作为溢出条件进行跟踪。
应用程序是否必须跟踪正在进行的操作的数量？或者，如果CQ已满，是否有一种更简单的方法来暂停向SQ的提交？
1条答案
按热度按时间e3bfsja21#
我的理解是，有两种可能的解决办法：
将
IORING_SETUP_CQ_NODROP标志设置为quote Jen Axboe将：稍微改变一下CQ环溢出的行为。首先，它不会溢出环，它只是存储我们无法放入CQ环的完成的积压。为了防止积压无限增长，如果积压是非空的，我们对提交的IO施加反压力。任何试图提交新IO的非空积压将得到-EBUSY从内核返回。这是给应用程序的一个信号，它已经积压了CQ事件，并且它必须在被允许提交更多IO之前获得这些事件。
因此，调用
io_uring_enter()将返回-EBUSY。另请参阅io_uring_queue_init文档。但是，如果我们使用内核线程来轮询提交队列（使用
IORING_SETUP_SQPOLL）呢？在这种情况下，我们没有调用io_uring_enter()，所以我们永远不会看到-EBUSY错误。我假设这里的解决方案是在尝试向提交队列提交任何内容之前调用liburing的
io_uring_cq_has_overflow()？