On 7/7/20 10:25 AM, Pavel Begunkov wrote: > ... >>>> >>>> To fix this issue, export cq overflow status to userspace, then >>>> helper functions() in liburing, such as io_uring_peek_cqe, can be >>>> aware of this cq overflow and do flush accordingly. >>> >>> Is there any way we can accomplish the same without exporting >>> another set of flags? Would it be enough for the SQPOLl thread to set >>> IORING_SQ_NEED_WAKEUP if we're in overflow condition? That should >>> result in the app entering the kernel when it's flushed the user CQ >>> side, and then the sqthread could attempt to flush the pending >>> events as well. >>> >>> Something like this, totally untested... >> >> OK, took a closer look at this, it's a generic thing, not just >> SQPOLL related. My bad! >> >> Anyway, my suggestion would be to add IORING_SQ_CQ_OVERFLOW to the >> existing flags, and then make a liburing change almost identical to >> what you had. > > How about CQ being full as an indicator that flush is required? > With a properly set CQ size there shouldn't be much false positives. I guess my worry there would be that it makes the state more tricky. When you do the first peek/get, the ring is full but you can't flush at that point. You'd really want to flush when the ring is now empty, AND it used to be full, and you get -EAGAIN. -- Jens Axboe
