liburing icon indicating copy to clipboard operation
liburing copied to clipboard

Add support for absolute timeouts to io_uring_getevents_arg-based io_uring_enter calls

Open lewissbaker opened this issue 1 year ago • 8 comments

I have been working on implementing an io_uring-based execution context with support for timers where I manage a priority-queue of user-provided timers and compute the earliest due time at which I have work scheduled to run.

Ideally, I would like to be able to call io_uring_enter2() and have that block until either I have a completion-event to process or the earliest due time has elapsed.

Currently, the io_uring_getevents_arg structure seems to require passing a relative time.

While the documentation does not specify whether the time is relative or not, looking at the implementation, the io_cqring_wait() function seems to be adding the current kernel time to the value passed.

While I can convert the absolute time I have to a relative time by calling clock_gettime() just before calling io_uring_enter2(), this approach has a couple of limitations.

  1. It seems like additional overhead - both user-space and the kernel need to ask for the current time to convert to/from a relative time.
  2. It can also be less accurate than passing an absolute time - if the thread's time-slice ends between the calls to clock_gettime() and io_uring_enter2() then the computed relative timeout can be an over-estimate and can result in additional delay to the io_uring_enter2() call returning.

Would it be possible to add support for passing an absolute timeout time to the io_uring_enter2() syscall or to the io_uring_wait_cqe_timeout() or io_uring_submit_and_wait_timeout() functions? Ideally, with the ability to specify which clock to use (e.g. CLOCK_BOOTTIME or CLOCK_MONOTONIC).

Or am I better off trying to use the IORING_OP_TIMEOUT op-code for this use-case?

lewissbaker avatar Jun 03 '24 13:06 lewissbaker