public Class LibIOURing

io-wq worker categories Enum values:

• IO_WQ_BOUND
• IO_WQ_UNBOUND

ASYNC_CANCEL flags.

ASYNC_CANCEL flags.

cq_ring->flags Enum values:

• CQ_EVENTFD_DISABLED - disable eventfd notifications

cqe->flags Enum values:

• CQE_F_BUFFER - If set, the upper 16 bits are the buffer ID
• CQE_F_MORE - If set, parent SQE will generate more CQE entries
• CQE_F_SOCK_NONEMPTY - If set, more data to read after socket recv.
• CQE_F_NOTIF - Set for notification CQEs. Can be used to distinct them from sends.

cqe->flags Enum values:

• CQE_F_BUFFER - If set, the upper 16 bits are the buffer ID
• CQE_F_MORE - If set, parent SQE will generate more CQE entries
• CQE_F_SOCK_NONEMPTY - If set, more data to read after socket recv.
• CQE_F_NOTIF - Set for notification CQEs. Can be used to distinct them from sends.

io_uring_enter(2) flags Enum values:

• ENTER_GETEVENTS - If this flag is set, then the system call will wait for the specificied number of events in min_complete before returning.

  This flag can be set along with to_submit to both submit and complete events in a single system call.

• ENTER_SQ_WAKEUP - If the ring has been created with SETUP_SQPOLL, then this flag asks the kernel to wakeup the SQ kernel thread to submit IO.
• ENTER_SQ_WAIT - If the ring has been created with SETUP_SQPOLL, then the application has no real insight into when the SQ kernel thread has consumed entries from the SQ ring. This can lead to a situation where the application can no longer get a free SQE entry to submit, without knowing when it one becomes available as the SQ kernel thread consumes them. If the system call is used with this flag set, then it will wait until at least one entry is free in the SQ ring.
• ENTER_EXT_ARG - Since kernel 5.11, the system calls arguments have been modified to look like the following:

  
  int io_uring_enter(unsigned int fd, unsigned int to_submit,
                     unsigned int min_complete, unsigned int flags,
                     const void *arg, size_t argsz);

io_uring_enter(2) flags Enum values:

• ENTER_GETEVENTS - If this flag is set, then the system call will wait for the specificied number of events in min_complete before returning.

  This flag can be set along with to_submit to both submit and complete events in a single system call.

• ENTER_SQ_WAKEUP - If the ring has been created with SETUP_SQPOLL, then this flag asks the kernel to wakeup the SQ kernel thread to submit IO.
• ENTER_SQ_WAIT - If the ring has been created with SETUP_SQPOLL, then the application has no real insight into when the SQ kernel thread has consumed entries from the SQ ring. This can lead to a situation where the application can no longer get a free SQE entry to submit, without knowing when it one becomes available as the SQ kernel thread consumes them. If the system call is used with this flag set, then it will wait until at least one entry is free in the SQ ring.
• ENTER_EXT_ARG - Since kernel 5.11, the system calls arguments have been modified to look like the following:

  
  int io_uring_enter(unsigned int fd, unsigned int to_submit,
                     unsigned int min_complete, unsigned int flags,
                     const void *arg, size_t argsz);

io_uring_enter(2) flags Enum values:

• ENTER_GETEVENTS - If this flag is set, then the system call will wait for the specificied number of events in min_complete before returning.

  This flag can be set along with to_submit to both submit and complete events in a single system call.

• ENTER_SQ_WAKEUP - If the ring has been created with SETUP_SQPOLL, then this flag asks the kernel to wakeup the SQ kernel thread to submit IO.
• ENTER_SQ_WAIT - If the ring has been created with SETUP_SQPOLL, then the application has no real insight into when the SQ kernel thread has consumed entries from the SQ ring. This can lead to a situation where the application can no longer get a free SQE entry to submit, without knowing when it one becomes available as the SQ kernel thread consumes them. If the system call is used with this flag set, then it will wait until at least one entry is free in the SQ ring.
• ENTER_EXT_ARG - Since kernel 5.11, the system calls arguments have been modified to look like the following:

  
  int io_uring_enter(unsigned int fd, unsigned int to_submit,
                     unsigned int min_complete, unsigned int flags,
                     const void *arg, size_t argsz);

io_uring_params->features flags Enum values:

• FEAT_SINGLE_MMAP - If this flag is set, the two SQ and CQ rings can be mapped with a single mmap(2) call.

  The SQEs must still be allocated separately. This brings the necessary mmap(2) calls down from three to two.

  Available since kernel 5.4.

• FEAT_NODROP - If this flag is set, io_uring supports never dropping completion events.

  If a completion event occurs and the CQ ring is full, the kernel stores the event internally until such a time that the CQ ring has room for more entries. If this overflow condition is entered, attempting to submit more IO will fail with the -EBUSY error value, if it can't flush the overflown events to the CQ ring. If this happens, the application must reap events from the CQ ring and attempt the submit again.

  Available since kernel 5.5.

• FEAT_SUBMIT_STABLE - If this flag is set, applications can be certain that any data for async offload has been consumed when the kernel has consumed the SQE.

  Available since kernel 5.5.

• FEAT_RW_CUR_POS - If this flag is set, applications can specify offset == -1 with IORING_OP_{READV,WRITEV}, IORING_OP_{READ,WRITE}_FIXED, and IORING_OP_{READ,WRITE} to mean current file position, which behaves like preadv2(2) and pwritev2(2) with offset == -1.

  It'll use (and update) the current file position. This obviously comes with the caveat that if the application has multiple reads or writes in flight, then the end result will not be as expected. This is similar to threads sharing a file descriptor and doing IO using the current file position.

  Available since kernel 5.6.

• FEAT_CUR_PERSONALITY - If this flag is set, then io_uring guarantees that both sync and async execution of a request assumes the credentials of the task that called enter to queue the requests.

  If this flag isn't set, then requests are issued with the credentials of the task that originally registered the io_uring. If only one task is using a ring, then this flag doesn't matter as the credentials will always be the same. Note that this is the default behavior, tasks can still register different personalities through register with REGISTER_PERSONALITY and specify the personality to use in the sqe.

  Available since kernel 5.6.

• FEAT_FAST_POLL - If this flag is set, then io_uring supports using an internal poll mechanism to drive data/space readiness.

  This means that requests that cannot read or write data to a file no longer need to be punted to an async thread for handling, instead they will begin operation when the file is ready. This is similar to doing poll + read/write in userspace, but eliminates the need to do so. If this flag is set, requests waiting on space/data consume a lot less resources doing so as they are not blocking a thread.

  Available since kernel 5.7.

• FEAT_POLL_32BITS - If this flag is set, the OP_POLL_ADD command accepts the full 32-bit range of epoll based flags.

  Most notably EPOLLEXCLUSIVE which allows exclusive (waking single waiters) behavior.

  Available since kernel 5.9.

• FEAT_SQPOLL_NONFIXED - If this flag is set, the SETUP_SQPOLL feature no longer requires the use of fixed files.

  Any normal file descriptor can be used for IO commands without needing registration.

  Available since kernel 5.11.

• FEAT_EXT_ARG - If this flag is set, then the enter system call supports passing in an extended argument instead of just the sigset_t of earlier kernels.

  This extended argument is of type struct io_uring_getevents_arg and allows the caller to pass in both a sigset_t and a timeout argument for waiting on events. A pointer to this struct must be passed in if ENTER_EXT_ARG is set in the flags for the enter system call.

  Available since kernel 5.11.

• FEAT_NATIVE_WORKERS - If this flag is set, io_uring is using native workers for its async helpers.

  Previous kernels used kernel threads that assumed the identity of the original io_uring owning task, but later kernels will actively create what looks more like regular process threads instead.

  Available since kernel 5.12.

• FEAT_RSRC_TAGS - If this flag is set, then io_uring supports a variety of features related to fixed files and buffers.

  In particular, it indicates that registered buffers can be updated in-place, whereas before the full set would have to be unregistered first.

  Available since kernel 5.13.

• FEAT_CQE_SKIP - If this flag is set, then io_uring supports setting IOSQE_CQE_SKIP_SUCCESS in the submitted SQE, indicating that no CQE should be generated for this SQE if it executes normally. If an error happens processing the SQE, a CQE with the appropriate error value will still be generated.

  Available since kernel 5.17.

• FEAT_LINKED_FILE - If this flag is set, then io_uring supports sane assignment of files for SQEs that have dependencies. For example, if a chain of SQEs are submitted with IOSQE_IO_LINK, then kernels without this flag will prepare the file for each link upfront. If a previous link opens a file with a known index, eg if direct descriptors are used with open or accept, then file assignment needs to happen post execution of that SQE. If this flag is set, then the kernel will defer file assignment until execution of a given request is started.

  Available since kernel 5.17.

• FEAT_REG_REG_RING

io_uring_params->features flags Enum values:

• FEAT_SINGLE_MMAP - If this flag is set, the two SQ and CQ rings can be mapped with a single mmap(2) call.

  The SQEs must still be allocated separately. This brings the necessary mmap(2) calls down from three to two.

  Available since kernel 5.4.

• FEAT_NODROP - If this flag is set, io_uring supports never dropping completion events.

  If a completion event occurs and the CQ ring is full, the kernel stores the event internally until such a time that the CQ ring has room for more entries. If this overflow condition is entered, attempting to submit more IO will fail with the -EBUSY error value, if it can't flush the overflown events to the CQ ring. If this happens, the application must reap events from the CQ ring and attempt the submit again.

  Available since kernel 5.5.

• FEAT_SUBMIT_STABLE - If this flag is set, applications can be certain that any data for async offload has been consumed when the kernel has consumed the SQE.

  Available since kernel 5.5.

• FEAT_RW_CUR_POS - If this flag is set, applications can specify offset == -1 with IORING_OP_{READV,WRITEV}, IORING_OP_{READ,WRITE}_FIXED, and IORING_OP_{READ,WRITE} to mean current file position, which behaves like preadv2(2) and pwritev2(2) with offset == -1.

  It'll use (and update) the current file position. This obviously comes with the caveat that if the application has multiple reads or writes in flight, then the end result will not be as expected. This is similar to threads sharing a file descriptor and doing IO using the current file position.

  Available since kernel 5.6.

• FEAT_CUR_PERSONALITY - If this flag is set, then io_uring guarantees that both sync and async execution of a request assumes the credentials of the task that called enter to queue the requests.

  If this flag isn't set, then requests are issued with the credentials of the task that originally registered the io_uring. If only one task is using a ring, then this flag doesn't matter as the credentials will always be the same. Note that this is the default behavior, tasks can still register different personalities through register with REGISTER_PERSONALITY and specify the personality to use in the sqe.

  Available since kernel 5.6.

• FEAT_FAST_POLL - If this flag is set, then io_uring supports using an internal poll mechanism to drive data/space readiness.

  This means that requests that cannot read or write data to a file no longer need to be punted to an async thread for handling, instead they will begin operation when the file is ready. This is similar to doing poll + read/write in userspace, but eliminates the need to do so. If this flag is set, requests waiting on space/data consume a lot less resources doing so as they are not blocking a thread.

  Available since kernel 5.7.

• FEAT_POLL_32BITS - If this flag is set, the OP_POLL_ADD command accepts the full 32-bit range of epoll based flags.

  Most notably EPOLLEXCLUSIVE which allows exclusive (waking single waiters) behavior.

  Available since kernel 5.9.

• FEAT_SQPOLL_NONFIXED - If this flag is set, the SETUP_SQPOLL feature no longer requires the use of fixed files.

  Any normal file descriptor can be used for IO commands without needing registration.

  Available since kernel 5.11.

• FEAT_EXT_ARG - If this flag is set, then the enter system call supports passing in an extended argument instead of just the sigset_t of earlier kernels.

  This extended argument is of type struct io_uring_getevents_arg and allows the caller to pass in both a sigset_t and a timeout argument for waiting on events. A pointer to this struct must be passed in if ENTER_EXT_ARG is set in the flags for the enter system call.

  Available since kernel 5.11.

• FEAT_NATIVE_WORKERS - If this flag is set, io_uring is using native workers for its async helpers.

  Previous kernels used kernel threads that assumed the identity of the original io_uring owning task, but later kernels will actively create what looks more like regular process threads instead.

  Available since kernel 5.12.

• FEAT_RSRC_TAGS - If this flag is set, then io_uring supports a variety of features related to fixed files and buffers.

  In particular, it indicates that registered buffers can be updated in-place, whereas before the full set would have to be unregistered first.

  Available since kernel 5.13.

• FEAT_CQE_SKIP - If this flag is set, then io_uring supports setting IOSQE_CQE_SKIP_SUCCESS in the submitted SQE, indicating that no CQE should be generated for this SQE if it executes normally. If an error happens processing the SQE, a CQE with the appropriate error value will still be generated.

  Available since kernel 5.17.

• FEAT_LINKED_FILE - If this flag is set, then io_uring supports sane assignment of files for SQEs that have dependencies. For example, if a chain of SQEs are submitted with IOSQE_IO_LINK, then kernels without this flag will prepare the file for each link upfront. If a previous link opens a file with a known index, eg if direct descriptors are used with open or accept, then file assignment needs to happen post execution of that SQE. If this flag is set, then the kernel will defer file assignment until execution of a given request is started.

  Available since kernel 5.17.

• FEAT_REG_REG_RING

io_uring_params->features flags Enum values:

• FEAT_SINGLE_MMAP - If this flag is set, the two SQ and CQ rings can be mapped with a single mmap(2) call.

  The SQEs must still be allocated separately. This brings the necessary mmap(2) calls down from three to two.

  Available since kernel 5.4.

• FEAT_NODROP - If this flag is set, io_uring supports never dropping completion events.

  If a completion event occurs and the CQ ring is full, the kernel stores the event internally until such a time that the CQ ring has room for more entries. If this overflow condition is entered, attempting to submit more IO will fail with the -EBUSY error value, if it can't flush the overflown events to the CQ ring. If this happens, the application must reap events from the CQ ring and attempt the submit again.

  Available since kernel 5.5.

• FEAT_SUBMIT_STABLE - If this flag is set, applications can be certain that any data for async offload has been consumed when the kernel has consumed the SQE.

  Available since kernel 5.5.

• FEAT_RW_CUR_POS - If this flag is set, applications can specify offset == -1 with IORING_OP_{READV,WRITEV}, IORING_OP_{READ,WRITE}_FIXED, and IORING_OP_{READ,WRITE} to mean current file position, which behaves like preadv2(2) and pwritev2(2) with offset == -1.

  It'll use (and update) the current file position. This obviously comes with the caveat that if the application has multiple reads or writes in flight, then the end result will not be as expected. This is similar to threads sharing a file descriptor and doing IO using the current file position.

  Available since kernel 5.6.

• FEAT_CUR_PERSONALITY - If this flag is set, then io_uring guarantees that both sync and async execution of a request assumes the credentials of the task that called enter to queue the requests.

  If this flag isn't set, then requests are issued with the credentials of the task that originally registered the io_uring. If only one task is using a ring, then this flag doesn't matter as the credentials will always be the same. Note that this is the default behavior, tasks can still register different personalities through register with REGISTER_PERSONALITY and specify the personality to use in the sqe.

  Available since kernel 5.6.

• FEAT_FAST_POLL - If this flag is set, then io_uring supports using an internal poll mechanism to drive data/space readiness.

  This means that requests that cannot read or write data to a file no longer need to be punted to an async thread for handling, instead they will begin operation when the file is ready. This is similar to doing poll + read/write in userspace, but eliminates the need to do so. If this flag is set, requests waiting on space/data consume a lot less resources doing so as they are not blocking a thread.

  Available since kernel 5.7.

• FEAT_POLL_32BITS - If this flag is set, the OP_POLL_ADD command accepts the full 32-bit range of epoll based flags.

  Most notably EPOLLEXCLUSIVE which allows exclusive (waking single waiters) behavior.

  Available since kernel 5.9.

• FEAT_SQPOLL_NONFIXED - If this flag is set, the SETUP_SQPOLL feature no longer requires the use of fixed files.

  Any normal file descriptor can be used for IO commands without needing registration.

  Available since kernel 5.11.

• FEAT_EXT_ARG - If this flag is set, then the enter system call supports passing in an extended argument instead of just the sigset_t of earlier kernels.

  This extended argument is of type struct io_uring_getevents_arg and allows the caller to pass in both a sigset_t and a timeout argument for waiting on events. A pointer to this struct must be passed in if ENTER_EXT_ARG is set in the flags for the enter system call.

  Available since kernel 5.11.

• FEAT_NATIVE_WORKERS - If this flag is set, io_uring is using native workers for its async helpers.

  Previous kernels used kernel threads that assumed the identity of the original io_uring owning task, but later kernels will actively create what looks more like regular process threads instead.

  Available since kernel 5.12.

• FEAT_RSRC_TAGS - If this flag is set, then io_uring supports a variety of features related to fixed files and buffers.

  In particular, it indicates that registered buffers can be updated in-place, whereas before the full set would have to be unregistered first.

  Available since kernel 5.13.

• FEAT_CQE_SKIP - If this flag is set, then io_uring supports setting IOSQE_CQE_SKIP_SUCCESS in the submitted SQE, indicating that no CQE should be generated for this SQE if it executes normally. If an error happens processing the SQE, a CQE with the appropriate error value will still be generated.

  Available since kernel 5.17.

• FEAT_LINKED_FILE - If this flag is set, then io_uring supports sane assignment of files for SQEs that have dependencies. For example, if a chain of SQEs are submitted with IOSQE_IO_LINK, then kernels without this flag will prepare the file for each link upfront. If a previous link opens a file with a known index, eg if direct descriptors are used with open or accept, then file assignment needs to happen post execution of that SQE. If this flag is set, then the kernel will defer file assignment until execution of a given request is started.

  Available since kernel 5.17.

• FEAT_REG_REG_RING

io_uring_params->features flags Enum values:

• FEAT_SINGLE_MMAP - If this flag is set, the two SQ and CQ rings can be mapped with a single mmap(2) call.

  The SQEs must still be allocated separately. This brings the necessary mmap(2) calls down from three to two.

  Available since kernel 5.4.

• FEAT_NODROP - If this flag is set, io_uring supports never dropping completion events.

  If a completion event occurs and the CQ ring is full, the kernel stores the event internally until such a time that the CQ ring has room for more entries. If this overflow condition is entered, attempting to submit more IO will fail with the -EBUSY error value, if it can't flush the overflown events to the CQ ring. If this happens, the application must reap events from the CQ ring and attempt the submit again.

  Available since kernel 5.5.

• FEAT_SUBMIT_STABLE - If this flag is set, applications can be certain that any data for async offload has been consumed when the kernel has consumed the SQE.

  Available since kernel 5.5.

• FEAT_RW_CUR_POS - If this flag is set, applications can specify offset == -1 with IORING_OP_{READV,WRITEV}, IORING_OP_{READ,WRITE}_FIXED, and IORING_OP_{READ,WRITE} to mean current file position, which behaves like preadv2(2) and pwritev2(2) with offset == -1.

  It'll use (and update) the current file position. This obviously comes with the caveat that if the application has multiple reads or writes in flight, then the end result will not be as expected. This is similar to threads sharing a file descriptor and doing IO using the current file position.

  Available since kernel 5.6.

• FEAT_CUR_PERSONALITY - If this flag is set, then io_uring guarantees that both sync and async execution of a request assumes the credentials of the task that called enter to queue the requests.

  If this flag isn't set, then requests are issued with the credentials of the task that originally registered the io_uring. If only one task is using a ring, then this flag doesn't matter as the credentials will always be the same. Note that this is the default behavior, tasks can still register different personalities through register with REGISTER_PERSONALITY and specify the personality to use in the sqe.

  Available since kernel 5.6.

• FEAT_FAST_POLL - If this flag is set, then io_uring supports using an internal poll mechanism to drive data/space readiness.

  This means that requests that cannot read or write data to a file no longer need to be punted to an async thread for handling, instead they will begin operation when the file is ready. This is similar to doing poll + read/write in userspace, but eliminates the need to do so. If this flag is set, requests waiting on space/data consume a lot less resources doing so as they are not blocking a thread.

  Available since kernel 5.7.

• FEAT_POLL_32BITS - If this flag is set, the OP_POLL_ADD command accepts the full 32-bit range of epoll based flags.

  Most notably EPOLLEXCLUSIVE which allows exclusive (waking single waiters) behavior.

  Available since kernel 5.9.

• FEAT_SQPOLL_NONFIXED - If this flag is set, the SETUP_SQPOLL feature no longer requires the use of fixed files.

  Any normal file descriptor can be used for IO commands without needing registration.

  Available since kernel 5.11.

• FEAT_EXT_ARG - If this flag is set, then the enter system call supports passing in an extended argument instead of just the sigset_t of earlier kernels.

  This extended argument is of type struct io_uring_getevents_arg and allows the caller to pass in both a sigset_t and a timeout argument for waiting on events. A pointer to this struct must be passed in if ENTER_EXT_ARG is set in the flags for the enter system call.

  Available since kernel 5.11.

• FEAT_NATIVE_WORKERS - If this flag is set, io_uring is using native workers for its async helpers.

  Previous kernels used kernel threads that assumed the identity of the original io_uring owning task, but later kernels will actively create what looks more like regular process threads instead.

  Available since kernel 5.12.

• FEAT_RSRC_TAGS - If this flag is set, then io_uring supports a variety of features related to fixed files and buffers.

  In particular, it indicates that registered buffers can be updated in-place, whereas before the full set would have to be unregistered first.

  Available since kernel 5.13.

• FEAT_CQE_SKIP - If this flag is set, then io_uring supports setting IOSQE_CQE_SKIP_SUCCESS in the submitted SQE, indicating that no CQE should be generated for this SQE if it executes normally. If an error happens processing the SQE, a CQE with the appropriate error value will still be generated.

  Available since kernel 5.17.

• FEAT_LINKED_FILE - If this flag is set, then io_uring supports sane assignment of files for SQEs that have dependencies. For example, if a chain of SQEs are submitted with IOSQE_IO_LINK, then kernels without this flag will prepare the file for each link upfront. If a previous link opens a file with a known index, eg if direct descriptors are used with open or accept, then file assignment needs to happen post execution of that SQE. If this flag is set, then the kernel will defer file assignment until execution of a given request is started.

  Available since kernel 5.17.

• FEAT_REG_REG_RING

io_uring_params->features flags Enum values:

• FEAT_SINGLE_MMAP - If this flag is set, the two SQ and CQ rings can be mapped with a single mmap(2) call.

  The SQEs must still be allocated separately. This brings the necessary mmap(2) calls down from three to two.

  Available since kernel 5.4.

• FEAT_NODROP - If this flag is set, io_uring supports never dropping completion events.

  If a completion event occurs and the CQ ring is full, the kernel stores the event internally until such a time that the CQ ring has room for more entries. If this overflow condition is entered, attempting to submit more IO will fail with the -EBUSY error value, if it can't flush the overflown events to the CQ ring. If this happens, the application must reap events from the CQ ring and attempt the submit again.

  Available since kernel 5.5.

• FEAT_SUBMIT_STABLE - If this flag is set, applications can be certain that any data for async offload has been consumed when the kernel has consumed the SQE.

  Available since kernel 5.5.

• FEAT_RW_CUR_POS - If this flag is set, applications can specify offset == -1 with IORING_OP_{READV,WRITEV}, IORING_OP_{READ,WRITE}_FIXED, and IORING_OP_{READ,WRITE} to mean current file position, which behaves like preadv2(2) and pwritev2(2) with offset == -1.

  It'll use (and update) the current file position. This obviously comes with the caveat that if the application has multiple reads or writes in flight, then the end result will not be as expected. This is similar to threads sharing a file descriptor and doing IO using the current file position.

  Available since kernel 5.6.

• FEAT_CUR_PERSONALITY - If this flag is set, then io_uring guarantees that both sync and async execution of a request assumes the credentials of the task that called enter to queue the requests.

  If this flag isn't set, then requests are issued with the credentials of the task that originally registered the io_uring. If only one task is using a ring, then this flag doesn't matter as the credentials will always be the same. Note that this is the default behavior, tasks can still register different personalities through register with REGISTER_PERSONALITY and specify the personality to use in the sqe.

  Available since kernel 5.6.

• FEAT_FAST_POLL - If this flag is set, then io_uring supports using an internal poll mechanism to drive data/space readiness.

  This means that requests that cannot read or write data to a file no longer need to be punted to an async thread for handling, instead they will begin operation when the file is ready. This is similar to doing poll + read/write in userspace, but eliminates the need to do so. If this flag is set, requests waiting on space/data consume a lot less resources doing so as they are not blocking a thread.

  Available since kernel 5.7.

• FEAT_POLL_32BITS - If this flag is set, the OP_POLL_ADD command accepts the full 32-bit range of epoll based flags.

  Most notably EPOLLEXCLUSIVE which allows exclusive (waking single waiters) behavior.

  Available since kernel 5.9.

• FEAT_SQPOLL_NONFIXED - If this flag is set, the SETUP_SQPOLL feature no longer requires the use of fixed files.

  Any normal file descriptor can be used for IO commands without needing registration.

  Available since kernel 5.11.

• FEAT_EXT_ARG - If this flag is set, then the enter system call supports passing in an extended argument instead of just the sigset_t of earlier kernels.

  This extended argument is of type struct io_uring_getevents_arg and allows the caller to pass in both a sigset_t and a timeout argument for waiting on events. A pointer to this struct must be passed in if ENTER_EXT_ARG is set in the flags for the enter system call.

  Available since kernel 5.11.

• FEAT_NATIVE_WORKERS - If this flag is set, io_uring is using native workers for its async helpers.

  Previous kernels used kernel threads that assumed the identity of the original io_uring owning task, but later kernels will actively create what looks more like regular process threads instead.

  Available since kernel 5.12.

• FEAT_RSRC_TAGS - If this flag is set, then io_uring supports a variety of features related to fixed files and buffers.

  In particular, it indicates that registered buffers can be updated in-place, whereas before the full set would have to be unregistered first.

  Available since kernel 5.13.

• FEAT_CQE_SKIP - If this flag is set, then io_uring supports setting IOSQE_CQE_SKIP_SUCCESS in the submitted SQE, indicating that no CQE should be generated for this SQE if it executes normally. If an error happens processing the SQE, a CQE with the appropriate error value will still be generated.

  Available since kernel 5.17.

• FEAT_LINKED_FILE - If this flag is set, then io_uring supports sane assignment of files for SQEs that have dependencies. For example, if a chain of SQEs are submitted with IOSQE_IO_LINK, then kernels without this flag will prepare the file for each link upfront. If a previous link opens a file with a known index, eg if direct descriptors are used with open or accept, then file assignment needs to happen post execution of that SQE. If this flag is set, then the kernel will defer file assignment until execution of a given request is started.

  Available since kernel 5.17.

• FEAT_REG_REG_RING

io_uring_params->features flags Enum values:

• FEAT_SINGLE_MMAP - If this flag is set, the two SQ and CQ rings can be mapped with a single mmap(2) call.

  The SQEs must still be allocated separately. This brings the necessary mmap(2) calls down from three to two.

  Available since kernel 5.4.

• FEAT_NODROP - If this flag is set, io_uring supports never dropping completion events.

  If a completion event occurs and the CQ ring is full, the kernel stores the event internally until such a time that the CQ ring has room for more entries. If this overflow condition is entered, attempting to submit more IO will fail with the -EBUSY error value, if it can't flush the overflown events to the CQ ring. If this happens, the application must reap events from the CQ ring and attempt the submit again.

  Available since kernel 5.5.

• FEAT_SUBMIT_STABLE - If this flag is set, applications can be certain that any data for async offload has been consumed when the kernel has consumed the SQE.

  Available since kernel 5.5.

• FEAT_RW_CUR_POS - If this flag is set, applications can specify offset == -1 with IORING_OP_{READV,WRITEV}, IORING_OP_{READ,WRITE}_FIXED, and IORING_OP_{READ,WRITE} to mean current file position, which behaves like preadv2(2) and pwritev2(2) with offset == -1.

  It'll use (and update) the current file position. This obviously comes with the caveat that if the application has multiple reads or writes in flight, then the end result will not be as expected. This is similar to threads sharing a file descriptor and doing IO using the current file position.

  Available since kernel 5.6.

• FEAT_CUR_PERSONALITY - If this flag is set, then io_uring guarantees that both sync and async execution of a request assumes the credentials of the task that called enter to queue the requests.

  If this flag isn't set, then requests are issued with the credentials of the task that originally registered the io_uring. If only one task is using a ring, then this flag doesn't matter as the credentials will always be the same. Note that this is the default behavior, tasks can still register different personalities through register with REGISTER_PERSONALITY and specify the personality to use in the sqe.

  Available since kernel 5.6.

• FEAT_FAST_POLL - If this flag is set, then io_uring supports using an internal poll mechanism to drive data/space readiness.

  This means that requests that cannot read or write data to a file no longer need to be punted to an async thread for handling, instead they will begin operation when the file is ready. This is similar to doing poll + read/write in userspace, but eliminates the need to do so. If this flag is set, requests waiting on space/data consume a lot less resources doing so as they are not blocking a thread.

  Available since kernel 5.7.

• FEAT_POLL_32BITS - If this flag is set, the OP_POLL_ADD command accepts the full 32-bit range of epoll based flags.

  Most notably EPOLLEXCLUSIVE which allows exclusive (waking single waiters) behavior.

  Available since kernel 5.9.

• FEAT_SQPOLL_NONFIXED - If this flag is set, the SETUP_SQPOLL feature no longer requires the use of fixed files.

  Any normal file descriptor can be used for IO commands without needing registration.

  Available since kernel 5.11.

• FEAT_EXT_ARG - If this flag is set, then the enter system call supports passing in an extended argument instead of just the sigset_t of earlier kernels.

  This extended argument is of type struct io_uring_getevents_arg and allows the caller to pass in both a sigset_t and a timeout argument for waiting on events. A pointer to this struct must be passed in if ENTER_EXT_ARG is set in the flags for the enter system call.

  Available since kernel 5.11.

• FEAT_NATIVE_WORKERS - If this flag is set, io_uring is using native workers for its async helpers.

  Previous kernels used kernel threads that assumed the identity of the original io_uring owning task, but later kernels will actively create what looks more like regular process threads instead.

  Available since kernel 5.12.

• FEAT_RSRC_TAGS - If this flag is set, then io_uring supports a variety of features related to fixed files and buffers.

  In particular, it indicates that registered buffers can be updated in-place, whereas before the full set would have to be unregistered first.

  Available since kernel 5.13.

• FEAT_CQE_SKIP - If this flag is set, then io_uring supports setting IOSQE_CQE_SKIP_SUCCESS in the submitted SQE, indicating that no CQE should be generated for this SQE if it executes normally. If an error happens processing the SQE, a CQE with the appropriate error value will still be generated.

  Available since kernel 5.17.

• FEAT_LINKED_FILE - If this flag is set, then io_uring supports sane assignment of files for SQEs that have dependencies. For example, if a chain of SQEs are submitted with IOSQE_IO_LINK, then kernels without this flag will prepare the file for each link upfront. If a previous link opens a file with a known index, eg if direct descriptors are used with open or accept, then file assignment needs to happen post execution of that SQE. If this flag is set, then the kernel will defer file assignment until execution of a given request is started.

  Available since kernel 5.17.

• FEAT_REG_REG_RING

io_uring_params->features flags Enum values:

• FEAT_SINGLE_MMAP - If this flag is set, the two SQ and CQ rings can be mapped with a single mmap(2) call.

  The SQEs must still be allocated separately. This brings the necessary mmap(2) calls down from three to two.

  Available since kernel 5.4.

• FEAT_NODROP - If this flag is set, io_uring supports never dropping completion events.

  If a completion event occurs and the CQ ring is full, the kernel stores the event internally until such a time that the CQ ring has room for more entries. If this overflow condition is entered, attempting to submit more IO will fail with the -EBUSY error value, if it can't flush the overflown events to the CQ ring. If this happens, the application must reap events from the CQ ring and attempt the submit again.

  Available since kernel 5.5.

• FEAT_SUBMIT_STABLE - If this flag is set, applications can be certain that any data for async offload has been consumed when the kernel has consumed the SQE.

  Available since kernel 5.5.

• FEAT_RW_CUR_POS - If this flag is set, applications can specify offset == -1 with IORING_OP_{READV,WRITEV}, IORING_OP_{READ,WRITE}_FIXED, and IORING_OP_{READ,WRITE} to mean current file position, which behaves like preadv2(2) and pwritev2(2) with offset == -1.

  It'll use (and update) the current file position. This obviously comes with the caveat that if the application has multiple reads or writes in flight, then the end result will not be as expected. This is similar to threads sharing a file descriptor and doing IO using the current file position.

  Available since kernel 5.6.

• FEAT_CUR_PERSONALITY - If this flag is set, then io_uring guarantees that both sync and async execution of a request assumes the credentials of the task that called enter to queue the requests.

  If this flag isn't set, then requests are issued with the credentials of the task that originally registered the io_uring. If only one task is using a ring, then this flag doesn't matter as the credentials will always be the same. Note that this is the default behavior, tasks can still register different personalities through register with REGISTER_PERSONALITY and specify the personality to use in the sqe.

  Available since kernel 5.6.

• FEAT_FAST_POLL - If this flag is set, then io_uring supports using an internal poll mechanism to drive data/space readiness.

  This means that requests that cannot read or write data to a file no longer need to be punted to an async thread for handling, instead they will begin operation when the file is ready. This is similar to doing poll + read/write in userspace, but eliminates the need to do so. If this flag is set, requests waiting on space/data consume a lot less resources doing so as they are not blocking a thread.

  Available since kernel 5.7.

• FEAT_POLL_32BITS - If this flag is set, the OP_POLL_ADD command accepts the full 32-bit range of epoll based flags.

  Most notably EPOLLEXCLUSIVE which allows exclusive (waking single waiters) behavior.

  Available since kernel 5.9.

• FEAT_SQPOLL_NONFIXED - If this flag is set, the SETUP_SQPOLL feature no longer requires the use of fixed files.

  Any normal file descriptor can be used for IO commands without needing registration.

  Available since kernel 5.11.

• FEAT_EXT_ARG - If this flag is set, then the enter system call supports passing in an extended argument instead of just the sigset_t of earlier kernels.

  This extended argument is of type struct io_uring_getevents_arg and allows the caller to pass in both a sigset_t and a timeout argument for waiting on events. A pointer to this struct must be passed in if ENTER_EXT_ARG is set in the flags for the enter system call.

  Available since kernel 5.11.

• FEAT_NATIVE_WORKERS - If this flag is set, io_uring is using native workers for its async helpers.

  Previous kernels used kernel threads that assumed the identity of the original io_uring owning task, but later kernels will actively create what looks more like regular process threads instead.

  Available since kernel 5.12.

• FEAT_RSRC_TAGS - If this flag is set, then io_uring supports a variety of features related to fixed files and buffers.

  In particular, it indicates that registered buffers can be updated in-place, whereas before the full set would have to be unregistered first.

  Available since kernel 5.13.

• FEAT_CQE_SKIP - If this flag is set, then io_uring supports setting IOSQE_CQE_SKIP_SUCCESS in the submitted SQE, indicating that no CQE should be generated for this SQE if it executes normally. If an error happens processing the SQE, a CQE with the appropriate error value will still be generated.

  Available since kernel 5.17.

• FEAT_LINKED_FILE - If this flag is set, then io_uring supports sane assignment of files for SQEs that have dependencies. For example, if a chain of SQEs are submitted with IOSQE_IO_LINK, then kernels without this flag will prepare the file for each link upfront. If a previous link opens a file with a known index, eg if direct descriptors are used with open or accept, then file assignment needs to happen post execution of that SQE. If this flag is set, then the kernel will defer file assignment until execution of a given request is started.

  Available since kernel 5.17.

• FEAT_REG_REG_RING

sqe->fsync_flags

OP_MSG_RING flags (sqe->msg_ring_flags) Enum values:

• MSG_RING_CQE_SKIP - Don't post a CQE to the target ring. Not applicable for MSG_DATA, obviously.
• MSG_RING_FLAGS_PASS

OP_MSG_RING command types, stored in sqe->addr Enum values:

• MSG_DATA - pass sqe->len as res and off as user_data
• MSG_SEND_FD - send a registered fd to another ring

Magic offsets for the application to mmap the data it needs

Magic offsets for the application to mmap the data it needs

Magic offsets for the application to mmap the data it needs

io_uring_op Enum values:

• OP_NOP - Do not perform any I/O. This is useful for testing the performance of the io_uring implementation itself.
• OP_READV - Vectored read operation, similar to preadv2(2). If the file is not seekable, off must be set to zero.
• OP_WRITEV - Vectored write operation, similar to pwritev2(2). If the file is not seekable, off must be set to zero.
• OP_FSYNC - File sync. See also fsync(2).

  Note that, while I/O is initiated in the order in which it appears inthe submission queue, completions are unordered. For example, an application which places a write I/O followed by an fsync in the submission queue cannot expect the fsync to apply to the write. The two operations execute in parallel, so the fsync may complete before the write is issued to the storage. The same is also true for previously issued writes that have not completed prior to the fsync.

• OP_READ_FIXED - Read from pre-mapped buffers. See register for details on how to setup a context for fixed reads.
• OP_WRITE_FIXED - Write to pre-mapped buffers. See register for details on how to setup a context for fixed writes.
• OP_POLL_ADD - Poll the fd specified in the submission queue entry for the events specified in the poll_events field.

  Unlike poll or epoll without EPOLLONESHOT, by default this interface always works in one shot mode. That is, once the poll operation is completed, it will have to be resubmitted.

  If POLL_ADD_MULTI is set in the SQE len field, then the poll will work in multi shot mode instead. That means it'll repatedly trigger when the requested event becomes true, and hence multiple CQEs can be generated from this single SQE. The CQE flags field will have CQE_F_MORE set on completion if the application should expect further CQE entries from the original request. If this flag isn't set on completion, then the poll request has been terminated and no further events will be generated. This mode is available since 5.13.

  If POLL_UPDATE_EVENTS is set in the SQE len field, then the request will update an existing poll request with the mask of events passed in with this request. The lookup is based on the user_data field of the original SQE submitted, and this values is passed in the addr field of the SQE. This mode is available since 5.13.

  If POLL_UPDATE_USER_DATA is set in the SQE len field, then the request will update the user_data of an existing poll request based on the value passed in the off field. This mode is available since 5.13.

  This command works like an asyncpoll(2) and the completion event result is the returned mask of events. For the variants that update user_data or events, the completion result will be similar to OP_POLL_REMOVE.

• OP_POLL_REMOVE - Remove an existing poll request.

  If found, the res field of the struct io_uring_cqe will contain 0. If not found, res will contain -ENOENT, or -EALREADY if the poll request was in the process of completing already.

• OP_SYNC_FILE_RANGE - Issue the equivalent of a sync_file_range(2) on the file descriptor.

  The fd field is the file descriptor to sync, the off field holds the offset in bytes, the len field holds the length in bytes, and the sync_range_flags field holds the flags for the command. See also sync_file_range(2) for the general description of the related system call.

  Available since 5.2.

• OP_SENDMSG - Issue the equivalent of a sendmsg(2) system call.

  fd must be set to the socket file descriptor, addr must contain a pointer to the msghdr structure, and msg_flags holds the flags associated with the system call. See also sendmsg(2) for the general description of the related system call.

  Available since 5.3.

• OP_RECVMSG - Works just like OP_SENDMSG, except for recvmsg(2) instead. See the description of IORING_OP_SENDMSG.

  Available since 5.3.

• OP_TIMEOUT - This command will register a timeout operation.

  The addr field must contain a pointer to a struct timespec64 structure, len must contain 1 to signify one timespec64 structure, timeout_flags may contain TIMEOUT_ABS for an absolute timeout value, or 0 for a relative timeout. off may contain a completion event count. A timeout will trigger a wakeup event on the completion ring for anyone waiting for events. A timeout condition is met when either the specified timeout expires, or the specified number of events have completed. Either condition will trigger the event. If set to 0, completed events are not counted, which effectively acts like a timer. io_uring timeouts use the CLOCK_MONOTONIC clock source. The request will complete with -ETIME if the timeout got completed through expiration of the timer, or 0 if the timeout got completed through requests completing on their own. If the timeout was cancelled before it expired, the request will complete with -ECANCELED.

  Available since 5.4.

  Since 5.15, this command also supports the following modifiers in timeout_flags:

  • TIMEOUT_BOOTTIME: If set, then the clock source used is CLOCK_BOOTTIME instead of CLOCK_MONOTONIC. This clock source differs in that it includes time elapsed if the system was suspend while having a timeout request in-flight.
  • TIMEOUT_REALTIME: If set, then the clock source used is CLOCK_BOOTTIME instead of CLOCK_MONOTONIC.

io_uring_op Enum values:

• OP_NOP - Do not perform any I/O. This is useful for testing the performance of the io_uring implementation itself.
• OP_READV - Vectored read operation, similar to preadv2(2). If the file is not seekable, off must be set to zero.
• OP_WRITEV - Vectored write operation, similar to pwritev2(2). If the file is not seekable, off must be set to zero.
• OP_FSYNC - File sync. See also fsync(2).

  Note that, while I/O is initiated in the order in which it appears inthe submission queue, completions are unordered. For example, an application which places a write I/O followed by an fsync in the submission queue cannot expect the fsync to apply to the write. The two operations execute in parallel, so the fsync may complete before the write is issued to the storage. The same is also true for previously issued writes that have not completed prior to the fsync.

• OP_READ_FIXED - Read from pre-mapped buffers. See register for details on how to setup a context for fixed reads.
• OP_WRITE_FIXED - Write to pre-mapped buffers. See register for details on how to setup a context for fixed writes.
• OP_POLL_ADD - Poll the fd specified in the submission queue entry for the events specified in the poll_events field.

  Unlike poll or epoll without EPOLLONESHOT, by default this interface always works in one shot mode. That is, once the poll operation is completed, it will have to be resubmitted.

  If POLL_ADD_MULTI is set in the SQE len field, then the poll will work in multi shot mode instead. That means it'll repatedly trigger when the requested event becomes true, and hence multiple CQEs can be generated from this single SQE. The CQE flags field will have CQE_F_MORE set on completion if the application should expect further CQE entries from the original request. If this flag isn't set on completion, then the poll request has been terminated and no further events will be generated. This mode is available since 5.13.

  If POLL_UPDATE_EVENTS is set in the SQE len field, then the request will update an existing poll request with the mask of events passed in with this request. The lookup is based on the user_data field of the original SQE submitted, and this values is passed in the addr field of the SQE. This mode is available since 5.13.

  If POLL_UPDATE_USER_DATA is set in the SQE len field, then the request will update the user_data of an existing poll request based on the value passed in the off field. This mode is available since 5.13.

  This command works like an asyncpoll(2) and the completion event result is the returned mask of events. For the variants that update user_data or events, the completion result will be similar to OP_POLL_REMOVE.

• OP_POLL_REMOVE - Remove an existing poll request.

  If found, the res field of the struct io_uring_cqe will contain 0. If not found, res will contain -ENOENT, or -EALREADY if the poll request was in the process of completing already.

• OP_SYNC_FILE_RANGE - Issue the equivalent of a sync_file_range(2) on the file descriptor.

  The fd field is the file descriptor to sync, the off field holds the offset in bytes, the len field holds the length in bytes, and the sync_range_flags field holds the flags for the command. See also sync_file_range(2) for the general description of the related system call.

  Available since 5.2.

• OP_SENDMSG - Issue the equivalent of a sendmsg(2) system call.

  fd must be set to the socket file descriptor, addr must contain a pointer to the msghdr structure, and msg_flags holds the flags associated with the system call. See also sendmsg(2) for the general description of the related system call.

  Available since 5.3.

• OP_RECVMSG - Works just like OP_SENDMSG, except for recvmsg(2) instead. See the description of IORING_OP_SENDMSG.

  Available since 5.3.

• OP_TIMEOUT - This command will register a timeout operation.

  The addr field must contain a pointer to a struct timespec64 structure, len must contain 1 to signify one timespec64 structure, timeout_flags may contain TIMEOUT_ABS for an absolute timeout value, or 0 for a relative timeout. off may contain a completion event count. A timeout will trigger a wakeup event on the completion ring for anyone waiting for events. A timeout condition is met when either the specified timeout expires, or the specified number of events have completed. Either condition will trigger the event. If set to 0, completed events are not counted, which effectively acts like a timer. io_uring timeouts use the CLOCK_MONOTONIC clock source. The request will complete with -ETIME if the timeout got completed through expiration of the timer, or 0 if the timeout got completed through requests completing on their own. If the timeout was cancelled before it expired, the request will complete with -ECANCELED.

  Available since 5.4.

  Since 5.15, this command also supports the following modifiers in timeout_flags:

  • TIMEOUT_BOOTTIME: If set, then the clock source used is CLOCK_BOOTTIME instead of CLOCK_MONOTONIC. This clock source differs in that it includes time elapsed if the system was suspend while having a timeout request in-flight.
  • TIMEOUT_REALTIME: If set, then the clock source used is CLOCK_BOOTTIME instead of CLOCK_MONOTONIC.

io_uring_op Enum values:

• OP_NOP - Do not perform any I/O. This is useful for testing the performance of the io_uring implementation itself.
• OP_READV - Vectored read operation, similar to preadv2(2). If the file is not seekable, off must be set to zero.
• OP_WRITEV - Vectored write operation, similar to pwritev2(2). If the file is not seekable, off must be set to zero.
• OP_FSYNC - File sync. See also fsync(2).

  Note that, while I/O is initiated in the order in which it appears inthe submission queue, completions are unordered. For example, an application which places a write I/O followed by an fsync in the submission queue cannot expect the fsync to apply to the write. The two operations execute in parallel, so the fsync may complete before the write is issued to the storage. The same is also true for previously issued writes that have not completed prior to the fsync.

• OP_READ_FIXED - Read from pre-mapped buffers. See register for details on how to setup a context for fixed reads.
• OP_WRITE_FIXED - Write to pre-mapped buffers. See register for details on how to setup a context for fixed writes.
• OP_POLL_ADD - Poll the fd specified in the submission queue entry for the events specified in the poll_events field.

  Unlike poll or epoll without EPOLLONESHOT, by default this interface always works in one shot mode. That is, once the poll operation is completed, it will have to be resubmitted.

  If POLL_ADD_MULTI is set in the SQE len field, then the poll will work in multi shot mode instead. That means it'll repatedly trigger when the requested event becomes true, and hence multiple CQEs can be generated from this single SQE. The CQE flags field will have CQE_F_MORE set on completion if the application should expect further CQE entries from the original request. If this flag isn't set on completion, then the poll request has been terminated and no further events will be generated. This mode is available since 5.13.

  If POLL_UPDATE_EVENTS is set in the SQE len field, then the request will update an existing poll request with the mask of events passed in with this request. The lookup is based on the user_data field of the original SQE submitted, and this values is passed in the addr field of the SQE. This mode is available since 5.13.

  If POLL_UPDATE_USER_DATA is set in the SQE len field, then the request will update the user_data of an existing poll request based on the value passed in the off field. This mode is available since 5.13.

  This command works like an asyncpoll(2) and the completion event result is the returned mask of events. For the variants that update user_data or events, the completion result will be similar to OP_POLL_REMOVE.

• OP_POLL_REMOVE - Remove an existing poll request.

  If found, the res field of the struct io_uring_cqe will contain 0. If not found, res will contain -ENOENT, or -EALREADY if the poll request was in the process of completing already.

• OP_SYNC_FILE_RANGE - Issue the equivalent of a sync_file_range(2) on the file descriptor.

  The fd field is the file descriptor to sync, the off field holds the offset in bytes, the len field holds the length in bytes, and the sync_range_flags field holds the flags for the command. See also sync_file_range(2) for the general description of the related system call.

  Available since 5.2.

• OP_SENDMSG - Issue the equivalent of a sendmsg(2) system call.

  fd must be set to the socket file descriptor, addr must contain a pointer to the msghdr structure, and msg_flags holds the flags associated with the system call. See also sendmsg(2) for the general description of the related system call.

  Available since 5.3.

• OP_RECVMSG - Works just like OP_SENDMSG, except for recvmsg(2) instead. See the description of IORING_OP_SENDMSG.

  Available since 5.3.

• OP_TIMEOUT - This command will register a timeout operation.

  The addr field must contain a pointer to a struct timespec64 structure, len must contain 1 to signify one timespec64 structure, timeout_flags may contain TIMEOUT_ABS for an absolute timeout value, or 0 for a relative timeout. off may contain a completion event count. A timeout will trigger a wakeup event on the completion ring for anyone waiting for events. A timeout condition is met when either the specified timeout expires, or the specified number of events have completed. Either condition will trigger the event. If set to 0, completed events are not counted, which effectively acts like a timer. io_uring timeouts use the CLOCK_MONOTONIC clock source. The request will complete with -ETIME if the timeout got completed through expiration of the timer, or 0 if the timeout got completed through requests completing on their own. If the timeout was cancelled before it expired, the request will complete with -ECANCELED.

  Available since 5.4.

  Since 5.15, this command also supports the following modifiers in timeout_flags:

  • TIMEOUT_BOOTTIME: If set, then the clock source used is CLOCK_BOOTTIME instead of CLOCK_MONOTONIC. This clock source differs in that it includes time elapsed if the system was suspend while having a timeout request in-flight.
  • TIMEOUT_REALTIME: If set, then the clock source used is CLOCK_BOOTTIME instead of CLOCK_MONOTONIC.

io_uring_op Enum values:

• OP_NOP - Do not perform any I/O. This is useful for testing the performance of the io_uring implementation itself.
• OP_READV - Vectored read operation, similar to preadv2(2). If the file is not seekable, off must be set to zero.
• OP_WRITEV - Vectored write operation, similar to pwritev2(2). If the file is not seekable, off must be set to zero.
• OP_FSYNC - File sync. See also fsync(2).

  Note that, while I/O is initiated in the order in which it appears inthe submission queue, completions are unordered. For example, an application which places a write I/O followed by an fsync in the submission queue cannot expect the fsync to apply to the write. The two operations execute in parallel, so the fsync may complete before the write is issued to the storage. The same is also true for previously issued writes that have not completed prior to the fsync.

• OP_READ_FIXED - Read from pre-mapped buffers. See register for details on how to setup a context for fixed reads.
• OP_WRITE_FIXED - Write to pre-mapped buffers. See register for details on how to setup a context for fixed writes.
• OP_POLL_ADD - Poll the fd specified in the submission queue entry for the events specified in the poll_events field.

  Unlike poll or epoll without EPOLLONESHOT, by default this interface always works in one shot mode. That is, once the poll operation is completed, it will have to be resubmitted.

  If POLL_ADD_MULTI is set in the SQE len field, then the poll will work in multi shot mode instead. That means it'll repatedly trigger when the requested event becomes true, and hence multiple CQEs can be generated from this single SQE. The CQE flags field will have CQE_F_MORE set on completion if the application should expect further CQE entries from the original request. If this flag isn't set on completion, then the poll request has been terminated and no further events will be generated. This mode is available since 5.13.

  If POLL_UPDATE_EVENTS is set in the SQE len field, then the request will update an existing poll request with the mask of events passed in with this request. The lookup is based on the user_data field of the original SQE submitted, and this values is passed in the addr field of the SQE. This mode is available since 5.13.

  If POLL_UPDATE_USER_DATA is set in the SQE len field, then the request will update the user_data of an existing poll request based on the value passed in the off field. This mode is available since 5.13.

  This command works like an asyncpoll(2) and the completion event result is the returned mask of events. For the variants that update user_data or events, the completion result will be similar to OP_POLL_REMOVE.

• OP_POLL_REMOVE - Remove an existing poll request.

  If found, the res field of the struct io_uring_cqe will contain 0. If not found, res will contain -ENOENT, or -EALREADY if the poll request was in the process of completing already.

• OP_SYNC_FILE_RANGE - Issue the equivalent of a sync_file_range(2) on the file descriptor.

  The fd field is the file descriptor to sync, the off field holds the offset in bytes, the len field holds the length in bytes, and the sync_range_flags field holds the flags for the command. See also sync_file_range(2) for the general description of the related system call.

  Available since 5.2.

• OP_SENDMSG - Issue the equivalent of a sendmsg(2) system call.

  fd must be set to the socket file descriptor, addr must contain a pointer to the msghdr structure, and msg_flags holds the flags associated with the system call. See also sendmsg(2) for the general description of the related system call.

  Available since 5.3.

• OP_RECVMSG - Works just like OP_SENDMSG, except for recvmsg(2) instead. See the description of IORING_OP_SENDMSG.

  Available since 5.3.

• OP_TIMEOUT - This command will register a timeout operation.

  The addr field must contain a pointer to a struct timespec64 structure, len must contain 1 to signify one timespec64 structure, timeout_flags may contain TIMEOUT_ABS for an absolute timeout value, or 0 for a relative timeout. off may contain a completion event count. A timeout will trigger a wakeup event on the completion ring for anyone waiting for events. A timeout condition is met when either the specified timeout expires, or the specified number of events have completed. Either condition will trigger the event. If set to 0, completed events are not counted, which effectively acts like a timer. io_uring timeouts use the CLOCK_MONOTONIC clock source. The request will complete with -ETIME if the timeout got completed through expiration of the timer, or 0 if the timeout got completed through requests completing on their own. If the timeout was cancelled before it expired, the request will complete with -ECANCELED.

  Available since 5.4.

  Since 5.15, this command also supports the following modifiers in timeout_flags:

  • TIMEOUT_BOOTTIME: If set, then the clock source used is CLOCK_BOOTTIME instead of CLOCK_MONOTONIC. This clock source differs in that it includes time elapsed if the system was suspend while having a timeout request in-flight.
  • TIMEOUT_REALTIME: If set, then the clock source used is CLOCK_BOOTTIME instead of CLOCK_MONOTONIC.

io_uring_op Enum values:

• OP_NOP - Do not perform any I/O. This is useful for testing the performance of the io_uring implementation itself.
• OP_READV - Vectored read operation, similar to preadv2(2). If the file is not seekable, off must be set to zero.
• OP_WRITEV - Vectored write operation, similar to pwritev2(2). If the file is not seekable, off must be set to zero.
• OP_FSYNC - File sync. See also fsync(2).

  Note that, while I/O is initiated in the order in which it appears inthe submission queue, completions are unordered. For example, an application which places a write I/O followed by an fsync in the submission queue cannot expect the fsync to apply to the write. The two operations execute in parallel, so the fsync may complete before the write is issued to the storage. The same is also true for previously issued writes that have not completed prior to the fsync.

• OP_READ_FIXED - Read from pre-mapped buffers. See register for details on how to setup a context for fixed reads.
• OP_WRITE_FIXED - Write to pre-mapped buffers. See register for details on how to setup a context for fixed writes.
• OP_POLL_ADD - Poll the fd specified in the submission queue entry for the events specified in the poll_events field.

  Unlike poll or epoll without EPOLLONESHOT, by default this interface always works in one shot mode. That is, once the poll operation is completed, it will have to be resubmitted.

  If POLL_ADD_MULTI is set in the SQE len field, then the poll will work in multi shot mode instead. That means it'll repatedly trigger when the requested event becomes true, and hence multiple CQEs can be generated from this single SQE. The CQE flags field will have CQE_F_MORE set on completion if the application should expect further CQE entries from the original request. If this flag isn't set on completion, then the poll request has been terminated and no further events will be generated. This mode is available since 5.13.

  If POLL_UPDATE_EVENTS is set in the SQE len field, then the request will update an existing poll request with the mask of events passed in with this request. The lookup is based on the user_data field of the original SQE submitted, and this values is passed in the addr field of the SQE. This mode is available since 5.13.

  If POLL_UPDATE_USER_DATA is set in the SQE len field, then the request will update the user_data of an existing poll request based on the value passed in the off field. This mode is available since 5.13.

  This command works like an asyncpoll(2) and the completion event result is the returned mask of events. For the variants that update user_data or events, the completion result will be similar to OP_POLL_REMOVE.

• OP_POLL_REMOVE - Remove an existing poll request.

  If found, the res field of the struct io_uring_cqe will contain 0. If not found, res will contain -ENOENT, or -EALREADY if the poll request was in the process of completing already.

• OP_SYNC_FILE_RANGE - Issue the equivalent of a sync_file_range(2) on the file descriptor.

  The fd field is the file descriptor to sync, the off field holds the offset in bytes, the len field holds the length in bytes, and the sync_range_flags field holds the flags for the command. See also sync_file_range(2) for the general description of the related system call.

  Available since 5.2.

• OP_SENDMSG - Issue the equivalent of a sendmsg(2) system call.

  fd must be set to the socket file descriptor, addr must contain a pointer to the msghdr structure, and msg_flags holds the flags associated with the system call. See also sendmsg(2) for the general description of the related system call.

  Available since 5.3.

• OP_RECVMSG - Works just like OP_SENDMSG, except for recvmsg(2) instead. See the description of IORING_OP_SENDMSG.

  Available since 5.3.

• OP_TIMEOUT - This command will register a timeout operation.

  The addr field must contain a pointer to a struct timespec64 structure, len must contain 1 to signify one timespec64 structure, timeout_flags may contain TIMEOUT_ABS for an absolute timeout value, or 0 for a relative timeout. off may contain a completion event count. A timeout will trigger a wakeup event on the completion ring for anyone waiting for events. A timeout condition is met when either the specified timeout expires, or the specified number of events have completed. Either condition will trigger the event. If set to 0, completed events are not counted, which effectively acts like a timer. io_uring timeouts use the CLOCK_MONOTONIC clock source. The request will complete with -ETIME if the timeout got completed through expiration of the timer, or 0 if the timeout got completed through requests completing on their own. If the timeout was cancelled before it expired, the request will complete with -ECANCELED.

  Available since 5.4.

  Since 5.15, this command also supports the following modifiers in timeout_flags:

  • TIMEOUT_BOOTTIME: If set, then the clock source used is CLOCK_BOOTTIME instead of CLOCK_MONOTONIC. This clock source differs in that it includes time elapsed if the system was suspend while having a timeout request in-flight.
  • TIMEOUT_REALTIME: If set, then the clock source used is CLOCK_BOOTTIME instead of CLOCK_MONOTONIC.

io_uring_op Enum values:

• OP_NOP - Do not perform any I/O. This is useful for testing the performance of the io_uring implementation itself.
• OP_READV - Vectored read operation, similar to preadv2(2). If the file is not seekable, off must be set to zero.
• OP_WRITEV - Vectored write operation, similar to pwritev2(2). If the file is not seekable, off must be set to zero.
• OP_FSYNC - File sync. See also fsync(2).

  Note that, while I/O is initiated in the order in which it appears inthe submission queue, completions are unordered. For example, an application which places a write I/O followed by an fsync in the submission queue cannot expect the fsync to apply to the write. The two operations execute in parallel, so the fsync may complete before the write is issued to the storage. The same is also true for previously issued writes that have not completed prior to the fsync.

• OP_READ_FIXED - Read from pre-mapped buffers. See register for details on how to setup a context for fixed reads.
• OP_WRITE_FIXED - Write to pre-mapped buffers. See register for details on how to setup a context for fixed writes.
• OP_POLL_ADD - Poll the fd specified in the submission queue entry for the events specified in the poll_events field.

  Unlike poll or epoll without EPOLLONESHOT, by default this interface always works in one shot mode. That is, once the poll operation is completed, it will have to be resubmitted.

  If POLL_ADD_MULTI is set in the SQE len field, then the poll will work in multi shot mode instead. That means it'll repatedly trigger when the requested event becomes true, and hence multiple CQEs can be generated from this single SQE. The CQE flags field will have CQE_F_MORE set on completion if the application should expect further CQE entries from the original request. If this flag isn't set on completion, then the poll request has been terminated and no further events will be generated. This mode is available since 5.13.

  If POLL_UPDATE_EVENTS is set in the SQE len field, then the request will update an existing poll request with the mask of events passed in with this request. The lookup is based on the user_data field of the original SQE submitted, and this values is passed in the addr field of the SQE. This mode is available since 5.13.

  If POLL_UPDATE_USER_DATA is set in the SQE len field, then the request will update the user_data of an existing poll request based on the value passed in the off field. This mode is available since 5.13.

  This command works like an asyncpoll(2) and the completion event result is the returned mask of events. For the variants that update user_data or events, the completion result will be similar to OP_POLL_REMOVE.

• OP_POLL_REMOVE - Remove an existing poll request.

  If found, the res field of the struct io_uring_cqe will contain 0. If not found, res will contain -ENOENT, or -EALREADY if the poll request was in the process of completing already.

• OP_SYNC_FILE_RANGE - Issue the equivalent of a sync_file_range(2) on the file descriptor.

  The fd field is the file descriptor to sync, the off field holds the offset in bytes, the len field holds the length in bytes, and the sync_range_flags field holds the flags for the command. See also sync_file_range(2) for the general description of the related system call.

  Available since 5.2.

• OP_SENDMSG - Issue the equivalent of a sendmsg(2) system call.

  fd must be set to the socket file descriptor, addr must contain a pointer to the msghdr structure, and msg_flags holds the flags associated with the system call. See also sendmsg(2) for the general description of the related system call.

  Available since 5.3.

• OP_RECVMSG - Works just like OP_SENDMSG, except for recvmsg(2) instead. See the description of IORING_OP_SENDMSG.

  Available since 5.3.

• OP_TIMEOUT - This command will register a timeout operation.

  The addr field must contain a pointer to a struct timespec64 structure, len must contain 1 to signify one timespec64 structure, timeout_flags may contain TIMEOUT_ABS for an absolute timeout value, or 0 for a relative timeout. off may contain a completion event count. A timeout will trigger a wakeup event on the completion ring for anyone waiting for events. A timeout condition is met when either the specified timeout expires, or the specified number of events have completed. Either condition will trigger the event. If set to 0, completed events are not counted, which effectively acts like a timer. io_uring timeouts use the CLOCK_MONOTONIC clock source. The request will complete with -ETIME if the timeout got completed through expiration of the timer, or 0 if the timeout got completed through requests completing on their own. If the timeout was cancelled before it expired, the request will complete with -ECANCELED.

  Available since 5.4.

  Since 5.15, this command also supports the following modifiers in timeout_flags:

  • TIMEOUT_BOOTTIME: If set, then the clock source used is CLOCK_BOOTTIME instead of CLOCK_MONOTONIC. This clock source differs in that it includes time elapsed if the system was suspend while having a timeout request in-flight.
  • TIMEOUT_REALTIME: If set, then the clock source used is CLOCK_BOOTTIME instead of CLOCK_MONOTONIC.

io_uring_op Enum values:

• OP_NOP - Do not perform any I/O. This is useful for testing the performance of the io_uring implementation itself.
• OP_READV - Vectored read operation, similar to preadv2(2). If the file is not seekable, off must be set to zero.
• OP_WRITEV - Vectored write operation, similar to pwritev2(2). If the file is not seekable, off must be set to zero.
• OP_FSYNC - File sync. See also fsync(2).

  Note that, while I/O is initiated in the order in which it appears inthe submission queue, completions are unordered. For example, an application which places a write I/O followed by an fsync in the submission queue cannot expect the fsync to apply to the write. The two operations execute in parallel, so the fsync may complete before the write is issued to the storage. The same is also true for previously issued writes that have not completed prior to the fsync.

• OP_READ_FIXED - Read from pre-mapped buffers. See register for details on how to setup a context for fixed reads.
• OP_WRITE_FIXED - Write to pre-mapped buffers. See register for details on how to setup a context for fixed writes.
• OP_POLL_ADD - Poll the fd specified in the submission queue entry for the events specified in the poll_events field.

  Unlike poll or epoll without EPOLLONESHOT, by default this interface always works in one shot mode. That is, once the poll operation is completed, it will have to be resubmitted.

  If POLL_ADD_MULTI is set in the SQE len field, then the poll will work in multi shot mode instead. That means it'll repatedly trigger when the requested event becomes true, and hence multiple CQEs can be generated from this single SQE. The CQE flags field will have CQE_F_MORE set on completion if the application should expect further CQE entries from the original request. If this flag isn't set on completion, then the poll request has been terminated and no further events will be generated. This mode is available since 5.13.

  If POLL_UPDATE_EVENTS is set in the SQE len field, then the request will update an existing poll request with the mask of events passed in with this request. The lookup is based on the user_data field of the original SQE submitted, and this values is passed in the addr field of the SQE. This mode is available since 5.13.

  If POLL_UPDATE_USER_DATA is set in the SQE len field, then the request will update the user_data of an existing poll request based on the value passed in the off field. This mode is available since 5.13.

  This command works like an asyncpoll(2) and the completion event result is the returned mask of events. For the variants that update user_data or events, the completion result will be similar to OP_POLL_REMOVE.

• OP_POLL_REMOVE - Remove an existing poll request.

  If found, the res field of the struct io_uring_cqe will contain 0. If not found, res will contain -ENOENT, or -EALREADY if the poll request was in the process of completing already.

• OP_SYNC_FILE_RANGE - Issue the equivalent of a sync_file_range(2) on the file descriptor.

  The fd field is the file descriptor to sync, the off field holds the offset in bytes, the len field holds the length in bytes, and the sync_range_flags field holds the flags for the command. See also sync_file_range(2) for the general description of the related system call.

  Available since 5.2.

• OP_SENDMSG - Issue the equivalent of a sendmsg(2) system call.

  fd must be set to the socket file descriptor, addr must contain a pointer to the msghdr structure, and msg_flags holds the flags associated with the system call. See also sendmsg(2) for the general description of the related system call.

  Available since 5.3.

• OP_RECVMSG - Works just like OP_SENDMSG, except for recvmsg(2) instead. See the description of IORING_OP_SENDMSG.

  Available since 5.3.

• OP_TIMEOUT - This command will register a timeout operation.

  The addr field must contain a pointer to a struct timespec64 structure, len must contain 1 to signify one timespec64 structure, timeout_flags may contain TIMEOUT_ABS for an absolute timeout value, or 0 for a relative timeout. off may contain a completion event count. A timeout will trigger a wakeup event on the completion ring for anyone waiting for events. A timeout condition is met when either the specified timeout expires, or the specified number of events have completed. Either condition will trigger the event. If set to 0, completed events are not counted, which effectively acts like a timer. io_uring timeouts use the CLOCK_MONOTONIC clock source. The request will complete with -ETIME if the timeout got completed through expiration of the timer, or 0 if the timeout got completed through requests completing on their own. If the timeout was cancelled before it expired, the request will complete with -ECANCELED.

  Available since 5.4.

  Since 5.15, this command also supports the following modifiers in timeout_flags:

  • TIMEOUT_BOOTTIME: If set, then the clock source used is CLOCK_BOOTTIME instead of CLOCK_MONOTONIC. This clock source differs in that it includes time elapsed if the system was suspend while having a timeout request in-flight.
  • TIMEOUT_REALTIME: If set, then the clock source used is CLOCK_BOOTTIME instead of CLOCK_MONOTONIC.

io_uring_op Enum values:

• OP_NOP - Do not perform any I/O. This is useful for testing the performance of the io_uring implementation itself.
• OP_READV - Vectored read operation, similar to preadv2(2). If the file is not seekable, off must be set to zero.
• OP_WRITEV - Vectored write operation, similar to pwritev2(2). If the file is not seekable, off must be set to zero.
• OP_FSYNC - File sync. See also fsync(2).

  Note that, while I/O is initiated in the order in which it appears inthe submission queue, completions are unordered. For example, an application which places a write I/O followed by an fsync in the submission queue cannot expect the fsync to apply to the write. The two operations execute in parallel, so the fsync may complete before the write is issued to the storage. The same is also true for previously issued writes that have not completed prior to the fsync.

• OP_READ_FIXED - Read from pre-mapped buffers. See register for details on how to setup a context for fixed reads.
• OP_WRITE_FIXED - Write to pre-mapped buffers. See register for details on how to setup a context for fixed writes.
• OP_POLL_ADD - Poll the fd specified in the submission queue entry for the events specified in the poll_events field.

  Unlike poll or epoll without EPOLLONESHOT, by default this interface always works in one shot mode. That is, once the poll operation is completed, it will have to be resubmitted.

  If POLL_ADD_MULTI is set in the SQE len field, then the poll will work in multi shot mode instead. That means it'll repatedly trigger when the requested event becomes true, and hence multiple CQEs can be generated from this single SQE. The CQE flags field will have CQE_F_MORE set on completion if the application should expect further CQE entries from the original request. If this flag isn't set on completion, then the poll request has been terminated and no further events will be generated. This mode is available since 5.13.

  If POLL_UPDATE_EVENTS is set in the SQE len field, then the request will update an existing poll request with the mask of events passed in with this request. The lookup is based on the user_data field of the original SQE submitted, and this values is passed in the addr field of the SQE. This mode is available since 5.13.

  If POLL_UPDATE_USER_DATA is set in the SQE len field, then the request will update the user_data of an existing poll request based on the value passed in the off field. This mode is available since 5.13.

  This command works like an asyncpoll(2) and the completion event result is the returned mask of events. For the variants that update user_data or events, the completion result will be similar to OP_POLL_REMOVE.

• OP_POLL_REMOVE - Remove an existing poll request.

  If found, the res field of the struct io_uring_cqe will contain 0. If not found, res will contain -ENOENT, or -EALREADY if the poll request was in the process of completing already.

• OP_SYNC_FILE_RANGE - Issue the equivalent of a sync_file_range(2) on the file descriptor.

  The fd field is the file descriptor to sync, the off field holds the offset in bytes, the len field holds the length in bytes, and the sync_range_flags field holds the flags for the command. See also sync_file_range(2) for the general description of the related system call.

  Available since 5.2.

• OP_SENDMSG - Issue the equivalent of a sendmsg(2) system call.

  fd must be set to the socket file descriptor, addr must contain a pointer to the msghdr structure, and msg_flags holds the flags associated with the system call. See also sendmsg(2) for the general description of the related system call.

  Available since 5.3.

• OP_RECVMSG - Works just like OP_SENDMSG, except for recvmsg(2) instead. See the description of IORING_OP_SENDMSG.

  Available since 5.3.

• OP_TIMEOUT - This command will register a timeout operation.

  The addr field must contain a pointer to a struct timespec64 structure, len must contain 1 to signify one timespec64 structure, timeout_flags may contain TIMEOUT_ABS for an absolute timeout value, or 0 for a relative timeout. off may contain a completion event count. A timeout will trigger a wakeup event on the completion ring for anyone waiting for events. A timeout condition is met when either the specified timeout expires, or the specified number of events have completed. Either condition will trigger the event. If set to 0, completed events are not counted, which effectively acts like a timer. io_uring timeouts use the CLOCK_MONOTONIC clock source. The request will complete with -ETIME if the timeout got completed through expiration of the timer, or 0 if the timeout got completed through requests completing on their own. If the timeout was cancelled before it expired, the request will complete with -ECANCELED.

  Available since 5.4.

  Since 5.15, this command also supports the following modifiers in timeout_flags:

  • TIMEOUT_BOOTTIME: If set, then the clock source used is CLOCK_BOOTTIME instead of CLOCK_MONOTONIC. This clock source differs in that it includes time elapsed if the system was suspend while having a timeout request in-flight.
  • TIMEOUT_REALTIME: If set, then the clock source used is CLOCK_BOOTTIME instead of CLOCK_MONOTONIC.

io_uring_op Enum values:

• OP_NOP - Do not perform any I/O. This is useful for testing the performance of the io_uring implementation itself.
• OP_READV - Vectored read operation, similar to preadv2(2). If the file is not seekable, off must be set to zero.
• OP_WRITEV - Vectored write operation, similar to pwritev2(2). If the file is not seekable, off must be set to zero.
• OP_FSYNC - File sync. See also fsync(2).

  Note that, while I/O is initiated in the order in which it appears inthe submission queue, completions are unordered. For example, an application which places a write I/O followed by an fsync in the submission queue cannot expect the fsync to apply to the write. The two operations execute in parallel, so the fsync may complete before the write is issued to the storage. The same is also true for previously issued writes that have not completed prior to the fsync.

• OP_READ_FIXED - Read from pre-mapped buffers. See register for details on how to setup a context for fixed reads.
• OP_WRITE_FIXED - Write to pre-mapped buffers. See register for details on how to setup a context for fixed writes.
• OP_POLL_ADD - Poll the fd specified in the submission queue entry for the events specified in the poll_events field.

  Unlike poll or epoll without EPOLLONESHOT, by default this interface always works in one shot mode. That is, once the poll operation is completed, it will have to be resubmitted.

  If POLL_ADD_MULTI is set in the SQE len field, then the poll will work in multi shot mode instead. That means it'll repatedly trigger when the requested event becomes true, and hence multiple CQEs can be generated from this single SQE. The CQE flags field will have CQE_F_MORE set on completion if the application should expect further CQE entries from the original request. If this flag isn't set on completion, then the poll request has been terminated and no further events will be generated. This mode is available since 5.13.

  If POLL_UPDATE_EVENTS is set in the SQE len field, then the request will update an existing poll request with the mask of events passed in with this request. The lookup is based on the user_data field of the original SQE submitted, and this values is passed in the addr field of the SQE. This mode is available since 5.13.

  If POLL_UPDATE_USER_DATA is set in the SQE len field, then the request will update the user_data of an existing poll request based on the value passed in the off field. This mode is available since 5.13.

  This command works like an asyncpoll(2) and the completion event result is the returned mask of events. For the variants that update user_data or events, the completion result will be similar to OP_POLL_REMOVE.

• OP_POLL_REMOVE - Remove an existing poll request.

  If found, the res field of the struct io_uring_cqe will contain 0. If not found, res will contain -ENOENT, or -EALREADY if the poll request was in the process of completing already.

• OP_SYNC_FILE_RANGE - Issue the equivalent of a sync_file_range(2) on the file descriptor.

  The fd field is the file descriptor to sync, the off field holds the offset in bytes, the len field holds the length in bytes, and the sync_range_flags field holds the flags for the command. See also sync_file_range(2) for the general description of the related system call.

  Available since 5.2.

• OP_SENDMSG - Issue the equivalent of a sendmsg(2) system call.

  fd must be set to the socket file descriptor, addr must contain a pointer to the msghdr structure, and msg_flags holds the flags associated with the system call. See also sendmsg(2) for the general description of the related system call.

  Available since 5.3.

• OP_RECVMSG - Works just like OP_SENDMSG, except for recvmsg(2) instead. See the description of IORING_OP_SENDMSG.

  Available since 5.3.

• OP_TIMEOUT - This command will register a timeout operation.

  The addr field must contain a pointer to a struct timespec64 structure, len must contain 1 to signify one timespec64 structure, timeout_flags may contain TIMEOUT_ABS for an absolute timeout value, or 0 for a relative timeout. off may contain a completion event count. A timeout will trigger a wakeup event on the completion ring for anyone waiting for events. A timeout condition is met when either the specified timeout expires, or the specified number of events have completed. Either condition will trigger the event. If set to 0, completed events are not counted, which effectively acts like a timer. io_uring timeouts use the CLOCK_MONOTONIC clock source. The request will complete with -ETIME if the timeout got completed through expiration of the timer, or 0 if the timeout got completed through requests completing on their own. If the timeout was cancelled before it expired, the request will complete with -ECANCELED.

  Available since 5.4.

  Since 5.15, this command also supports the following modifiers in timeout_flags:

  • TIMEOUT_BOOTTIME: If set, then the clock source used is CLOCK_BOOTTIME instead of CLOCK_MONOTONIC. This clock source differs in that it includes time elapsed if the system was suspend while having a timeout request in-flight.
  • TIMEOUT_REALTIME: If set, then the clock source used is CLOCK_BOOTTIME instead of CLOCK_MONOTONIC.

io_uring_op Enum values:

• OP_NOP - Do not perform any I/O. This is useful for testing the performance of the io_uring implementation itself.
• OP_READV - Vectored read operation, similar to preadv2(2). If the file is not seekable, off must be set to zero.
• OP_WRITEV - Vectored write operation, similar to pwritev2(2). If the file is not seekable, off must be set to zero.
• OP_FSYNC - File sync. See also fsync(2).

  Note that, while I/O is initiated in the order in which it appears inthe submission queue, completions are unordered. For example, an application which places a write I/O followed by an fsync in the submission queue cannot expect the fsync to apply to the write. The two operations execute in parallel, so the fsync may complete before the write is issued to the storage. The same is also true for previously issued writes that have not completed prior to the fsync.

• OP_READ_FIXED - Read from pre-mapped buffers. See register for details on how to setup a context for fixed reads.
• OP_WRITE_FIXED - Write to pre-mapped buffers. See register for details on how to setup a context for fixed writes.
• OP_POLL_ADD - Poll the fd specified in the submission queue entry for the events specified in the poll_events field.

  Unlike poll or epoll without EPOLLONESHOT, by default this interface always works in one shot mode. That is, once the poll operation is completed, it will have to be resubmitted.

  If POLL_ADD_MULTI is set in the SQE len field, then the poll will work in multi shot mode instead. That means it'll repatedly trigger when the requested event becomes true, and hence multiple CQEs can be generated from this single SQE. The CQE flags field will have CQE_F_MORE set on completion if the application should expect further CQE entries from the original request. If this flag isn't set on completion, then the poll request has been terminated and no further events will be generated. This mode is available since 5.13.

  If POLL_UPDATE_EVENTS is set in the SQE len field, then the request will update an existing poll request with the mask of events passed in with this request. The lookup is based on the user_data field of the original SQE submitted, and this values is passed in the addr field of the SQE. This mode is available since 5.13.

  If POLL_UPDATE_USER_DATA is set in the SQE len field, then the request will update the user_data of an existing poll request based on the value passed in the off field. This mode is available since 5.13.

  This command works like an asyncpoll(2) and the completion event result is the returned mask of events. For the variants that update user_data or events, the completion result will be similar to OP_POLL_REMOVE.

• OP_POLL_REMOVE - Remove an existing poll request.

  If found, the res field of the struct io_uring_cqe will contain 0. If not found, res will contain -ENOENT, or -EALREADY if the poll request was in the process of completing already.

• OP_SYNC_FILE_RANGE - Issue the equivalent of a sync_file_range(2) on the file descriptor.

  The fd field is the file descriptor to sync, the off field holds the offset in bytes, the len field holds the length in bytes, and the sync_range_flags field holds the flags for the command. See also sync_file_range(2) for the general description of the related system call.

  Available since 5.2.

• OP_SENDMSG - Issue the equivalent of a sendmsg(2) system call.

  fd must be set to the socket file descriptor, addr must contain a pointer to the msghdr structure, and msg_flags holds the flags associated with the system call. See also sendmsg(2) for the general description of the related system call.

  Available since 5.3.

• OP_RECVMSG - Works just like OP_SENDMSG, except for recvmsg(2) instead. See the description of IORING_OP_SENDMSG.

  Available since 5.3.

• OP_TIMEOUT - This command will register a timeout operation.

  The addr field must contain a pointer to a struct timespec64 structure, len must contain 1 to signify one timespec64 structure, timeout_flags may contain TIMEOUT_ABS for an absolute timeout value, or 0 for a relative timeout. off may contain a completion event count. A timeout will trigger a wakeup event on the completion ring for anyone waiting for events. A timeout condition is met when either the specified timeout expires, or the specified number of events have completed. Either condition will trigger the event. If set to 0, completed events are not counted, which effectively acts like a timer. io_uring timeouts use the CLOCK_MONOTONIC clock source. The request will complete with -ETIME if the timeout got completed through expiration of the timer, or 0 if the timeout got completed through requests completing on their own. If the timeout was cancelled before it expired, the request will complete with -ECANCELED.

  Available since 5.4.

  Since 5.15, this command also supports the following modifiers in timeout_flags:

  • TIMEOUT_BOOTTIME: If set, then the clock source used is CLOCK_BOOTTIME instead of CLOCK_MONOTONIC. This clock source differs in that it includes time elapsed if the system was suspend while having a timeout request in-flight.
  • TIMEOUT_REALTIME: If set, then the clock source used is CLOCK_BOOTTIME instead of CLOCK_MONOTONIC.

io_uring_op Enum values:

• OP_NOP - Do not perform any I/O. This is useful for testing the performance of the io_uring implementation itself.
• OP_READV - Vectored read operation, similar to preadv2(2). If the file is not seekable, off must be set to zero.
• OP_WRITEV - Vectored write operation, similar to pwritev2(2). If the file is not seekable, off must be set to zero.
• OP_FSYNC - File sync. See also fsync(2).

  Note that, while I/O is initiated in the order in which it appears inthe submission queue, completions are unordered. For example, an application which places a write I/O followed by an fsync in the submission queue cannot expect the fsync to apply to the write. The two operations execute in parallel, so the fsync may complete before the write is issued to the storage. The same is also true for previously issued writes that have not completed prior to the fsync.

• OP_READ_FIXED - Read from pre-mapped buffers. See register for details on how to setup a context for fixed reads.
• OP_WRITE_FIXED - Write to pre-mapped buffers. See register for details on how to setup a context for fixed writes.
• OP_POLL_ADD - Poll the fd specified in the submission queue entry for the events specified in the poll_events field.

  Unlike poll or epoll without EPOLLONESHOT, by default this interface always works in one shot mode. That is, once the poll operation is completed, it will have to be resubmitted.

  If POLL_ADD_MULTI is set in the SQE len field, then the poll will work in multi shot mode instead. That means it'll repatedly trigger when the requested event becomes true, and hence multiple CQEs can be generated from this single SQE. The CQE flags field will have CQE_F_MORE set on completion if the application should expect further CQE entries from the original request. If this flag isn't set on completion, then the poll request has been terminated and no further events will be generated. This mode is available since 5.13.

  If POLL_UPDATE_EVENTS is set in the SQE len field, then the request will update an existing poll request with the mask of events passed in with this request. The lookup is based on the user_data field of the original SQE submitted, and this values is passed in the addr field of the SQE. This mode is available since 5.13.

  If POLL_UPDATE_USER_DATA is set in the SQE len field, then the request will update the user_data of an existing poll request based on the value passed in the off field. This mode is available since 5.13.

  This command works like an asyncpoll(2) and the completion event result is the returned mask of events. For the variants that update user_data or events, the completion result will be similar to OP_POLL_REMOVE.

• OP_POLL_REMOVE - Remove an existing poll request.

  If found, the res field of the struct io_uring_cqe will contain 0. If not found, res will contain -ENOENT, or -EALREADY if the poll request was in the process of completing already.

• OP_SYNC_FILE_RANGE - Issue the equivalent of a sync_file_range(2) on the file descriptor.

  The fd field is the file descriptor to sync, the off field holds the offset in bytes, the len field holds the length in bytes, and the sync_range_flags field holds the flags for the command. See also sync_file_range(2) for the general description of the related system call.

  Available since 5.2.

• OP_SENDMSG - Issue the equivalent of a sendmsg(2) system call.

  fd must be set to the socket file descriptor, addr must contain a pointer to the msghdr structure, and msg_flags holds the flags associated with the system call. See also sendmsg(2) for the general description of the related system call.

  Available since 5.3.

• OP_RECVMSG - Works just like OP_SENDMSG, except for recvmsg(2) instead. See the description of IORING_OP_SENDMSG.

  Available since 5.3.

• OP_TIMEOUT - This command will register a timeout operation.

  The addr field must contain a pointer to a struct timespec64 structure, len must contain 1 to signify one timespec64 structure, timeout_flags may contain TIMEOUT_ABS for an absolute timeout value, or 0 for a relative timeout. off may contain a completion event count. A timeout will trigger a wakeup event on the completion ring for anyone waiting for events. A timeout condition is met when either the specified timeout expires, or the specified number of events have completed. Either condition will trigger the event. If set to 0, completed events are not counted, which effectively acts like a timer. io_uring timeouts use the CLOCK_MONOTONIC clock source. The request will complete with -ETIME if the timeout got completed through expiration of the timer, or 0 if the timeout got completed through requests completing on their own. If the timeout was cancelled before it expired, the request will complete with -ECANCELED.

  Available since 5.4.

  Since 5.15, this command also supports the following modifiers in timeout_flags:

  • TIMEOUT_BOOTTIME: If set, then the clock source used is CLOCK_BOOTTIME instead of CLOCK_MONOTONIC. This clock source differs in that it includes time elapsed if the system was suspend while having a timeout request in-flight.
  • TIMEOUT_REALTIME: If set, then the clock source used is CLOCK_BOOTTIME instead of CLOCK_MONOTONIC.

io_uring_op Enum values:

• OP_NOP - Do not perform any I/O. This is useful for testing the performance of the io_uring implementation itself.
• OP_READV - Vectored read operation, similar to preadv2(2). If the file is not seekable, off must be set to zero.
• OP_WRITEV - Vectored write operation, similar to pwritev2(2). If the file is not seekable, off must be set to zero.
• OP_FSYNC - File sync. See also fsync(2).

  Note that, while I/O is initiated in the order in which it appears inthe submission queue, completions are unordered. For example, an application which places a write I/O followed by an fsync in the submission queue cannot expect the fsync to apply to the write. The two operations execute in parallel, so the fsync may complete before the write is issued to the storage. The same is also true for previously issued writes that have not completed prior to the fsync.

• OP_READ_FIXED - Read from pre-mapped buffers. See register for details on how to setup a context for fixed reads.
• OP_WRITE_FIXED - Write to pre-mapped buffers. See register for details on how to setup a context for fixed writes.
• OP_POLL_ADD - Poll the fd specified in the submission queue entry for the events specified in the poll_events field.

  Unlike poll or epoll without EPOLLONESHOT, by default this interface always works in one shot mode. That is, once the poll operation is completed, it will have to be resubmitted.

  If POLL_ADD_MULTI is set in the SQE len field, then the poll will work in multi shot mode instead. That means it'll repatedly trigger when the requested event becomes true, and hence multiple CQEs can be generated from this single SQE. The CQE flags field will have CQE_F_MORE set on completion if the application should expect further CQE entries from the original request. If this flag isn't set on completion, then the poll request has been terminated and no further events will be generated. This mode is available since 5.13.

  If POLL_UPDATE_EVENTS is set in the SQE len field, then the request will update an existing poll request with the mask of events passed in with this request. The lookup is based on the user_data field of the original SQE submitted, and this values is passed in the addr field of the SQE. This mode is available since 5.13.

  If POLL_UPDATE_USER_DATA is set in the SQE len field, then the request will update the user_data of an existing poll request based on the value passed in the off field. This mode is available since 5.13.

  This command works like an asyncpoll(2) and the completion event result is the returned mask of events. For the variants that update user_data or events, the completion result will be similar to OP_POLL_REMOVE.

• OP_POLL_REMOVE - Remove an existing poll request.

  If found, the res field of the struct io_uring_cqe will contain 0. If not found, res will contain -ENOENT, or -EALREADY if the poll request was in the process of completing already.

• OP_SYNC_FILE_RANGE - Issue the equivalent of a sync_file_range(2) on the file descriptor.

  The fd field is the file descriptor to sync, the off field holds the offset in bytes, the len field holds the length in bytes, and the sync_range_flags field holds the flags for the command. See also sync_file_range(2) for the general description of the related system call.

  Available since 5.2.

• OP_SENDMSG - Issue the equivalent of a sendmsg(2) system call.

  fd must be set to the socket file descriptor, addr must contain a pointer to the msghdr structure, and msg_flags holds the flags associated with the system call. See also sendmsg(2) for the general description of the related system call.

  Available since 5.3.

• OP_RECVMSG - Works just like OP_SENDMSG, except for recvmsg(2) instead. See the description of IORING_OP_SENDMSG.

  Available since 5.3.

• OP_TIMEOUT - This command will register a timeout operation.

  The addr field must contain a pointer to a struct timespec64 structure, len must contain 1 to signify one timespec64 structure, timeout_flags may contain TIMEOUT_ABS for an absolute timeout value, or 0 for a relative timeout. off may contain a completion event count. A timeout will trigger a wakeup event on the completion ring for anyone waiting for events. A timeout condition is met when either the specified timeout expires, or the specified number of events have completed. Either condition will trigger the event. If set to 0, completed events are not counted, which effectively acts like a timer. io_uring timeouts use the CLOCK_MONOTONIC clock source. The request will complete with -ETIME if the timeout got completed through expiration of the timer, or 0 if the timeout got completed through requests completing on their own. If the timeout was cancelled before it expired, the request will complete with -ECANCELED.

  Available since 5.4.

  Since 5.15, this command also supports the following modifiers in timeout_flags:

  • TIMEOUT_BOOTTIME: If set, then the clock source used is CLOCK_BOOTTIME instead of CLOCK_MONOTONIC. This clock source differs in that it includes time elapsed if the system was suspend while having a timeout request in-flight.
  • TIMEOUT_REALTIME: If set, then the clock source used is CLOCK_BOOTTIME instead of CLOCK_MONOTONIC.

io_uring_op Enum values:

• OP_NOP - Do not perform any I/O. This is useful for testing the performance of the io_uring implementation itself.
• OP_READV - Vectored read operation, similar to preadv2(2). If the file is not seekable, off must be set to zero.
• OP_WRITEV - Vectored write operation, similar to pwritev2(2). If the file is not seekable, off must be set to zero.
• OP_FSYNC - File sync. See also fsync(2).

  Note that, while I/O is initiated in the order in which it appears inthe submission queue, completions are unordered. For example, an application which places a write I/O followed by an fsync in the submission queue cannot expect the fsync to apply to the write. The two operations execute in parallel, so the fsync may complete before the write is issued to the storage. The same is also true for previously issued writes that have not completed prior to the fsync.

• OP_READ_FIXED - Read from pre-mapped buffers. See register for details on how to setup a context for fixed reads.
• OP_WRITE_FIXED - Write to pre-mapped buffers. See register for details on how to setup a context for fixed writes.
• OP_POLL_ADD - Poll the fd specified in the submission queue entry for the events specified in the poll_events field.

  Unlike poll or epoll without EPOLLONESHOT, by default this interface always works in one shot mode. That is, once the poll operation is completed, it will have to be resubmitted.

  If POLL_ADD_MULTI is set in the SQE len field, then the poll will work in multi shot mode instead. That means it'll repatedly trigger when the requested event becomes true, and hence multiple CQEs can be generated from this single SQE. The CQE flags field will have CQE_F_MORE set on completion if the application should expect further CQE entries from the original request. If this flag isn't set on completion, then the poll request has been terminated and no further events will be generated. This mode is available since 5.13.

  If POLL_UPDATE_EVENTS is set in the SQE len field, then the request will update an existing poll request with the mask of events passed in with this request. The lookup is based on the user_data field of the original SQE submitted, and this values is passed in the addr field of the SQE. This mode is available since 5.13.

  If POLL_UPDATE_USER_DATA is set in the SQE len field, then the request will update the user_data of an existing poll request based on the value passed in the off field. This mode is available since 5.13.

  This command works like an asyncpoll(2) and the completion event result is the returned mask of events. For the variants that update user_data or events, the completion result will be similar to OP_POLL_REMOVE.

• OP_POLL_REMOVE - Remove an existing poll request.

  If found, the res field of the struct io_uring_cqe will contain 0. If not found, res will contain -ENOENT, or -EALREADY if the poll request was in the process of completing already.

• OP_SYNC_FILE_RANGE - Issue the equivalent of a sync_file_range(2) on the file descriptor.

  The fd field is the file descriptor to sync, the off field holds the offset in bytes, the len field holds the length in bytes, and the sync_range_flags field holds the flags for the command. See also sync_file_range(2) for the general description of the related system call.

  Available since 5.2.

• OP_SENDMSG - Issue the equivalent of a sendmsg(2) system call.

  fd must be set to the socket file descriptor, addr must contain a pointer to the msghdr structure, and msg_flags holds the flags associated with the system call. See also sendmsg(2) for the general description of the related system call.

  Available since 5.3.

• OP_RECVMSG - Works just like OP_SENDMSG, except for recvmsg(2) instead. See the description of IORING_OP_SENDMSG.

  Available since 5.3.

• OP_TIMEOUT - This command will register a timeout operation.

  The addr field must contain a pointer to a struct timespec64 structure, len must contain 1 to signify one timespec64 structure, timeout_flags may contain TIMEOUT_ABS for an absolute timeout value, or 0 for a relative timeout. off may contain a completion event count. A timeout will trigger a wakeup event on the completion ring for anyone waiting for events. A timeout condition is met when either the specified timeout expires, or the specified number of events have completed. Either condition will trigger the event. If set to 0, completed events are not counted, which effectively acts like a timer. io_uring timeouts use the CLOCK_MONOTONIC clock source. The request will complete with -ETIME if the timeout got completed through expiration of the timer, or 0 if the timeout got completed through requests completing on their own. If the timeout was cancelled before it expired, the request will complete with -ECANCELED.

  Available since 5.4.

  Since 5.15, this command also supports the following modifiers in timeout_flags:

  • TIMEOUT_BOOTTIME: If set, then the clock source used is CLOCK_BOOTTIME instead of CLOCK_MONOTONIC. This clock source differs in that it includes time elapsed if the system was suspend while having a timeout request in-flight.
  • TIMEOUT_REALTIME: If set, then the clock source used is CLOCK_BOOTTIME instead of CLOCK_MONOTONIC.

io_uring_op Enum values:

• OP_NOP - Do not perform any I/O. This is useful for testing the performance of the io_uring implementation itself.
• OP_READV - Vectored read operation, similar to preadv2(2). If the file is not seekable, off must be set to zero.
• OP_WRITEV - Vectored write operation, similar to pwritev2(2). If the file is not seekable, off must be set to zero.
• OP_FSYNC - File sync. See also fsync(2).

  Note that, while I/O is initiated in the order in which it appears inthe submission queue, completions are unordered. For example, an application which places a write I/O followed by an fsync in the submission queue cannot expect the fsync to apply to the write. The two operations execute in parallel, so the fsync may complete before the write is issued to the storage. The same is also true for previously issued writes that have not completed prior to the fsync.

• OP_READ_FIXED - Read from pre-mapped buffers. See register for details on how to setup a context for fixed reads.
• OP_WRITE_FIXED - Write to pre-mapped buffers. See register for details on how to setup a context for fixed writes.
• OP_POLL_ADD - Poll the fd specified in the submission queue entry for the events specified in the poll_events field.

  Unlike poll or epoll without EPOLLONESHOT, by default this interface always works in one shot mode. That is, once the poll operation is completed, it will have to be resubmitted.

  If POLL_ADD_MULTI is set in the SQE len field, then the poll will work in multi shot mode instead. That means it'll repatedly trigger when the requested event becomes true, and hence multiple CQEs can be generated from this single SQE. The CQE flags field will have CQE_F_MORE set on completion if the application should expect further CQE entries from the original request. If this flag isn't set on completion, then the poll request has been terminated and no further events will be generated. This mode is available since 5.13.

  If POLL_UPDATE_EVENTS is set in the SQE len field, then the request will update an existing poll request with the mask of events passed in with this request. The lookup is based on the user_data field of the original SQE submitted, and this values is passed in the addr field of the SQE. This mode is available since 5.13.

  If POLL_UPDATE_USER_DATA is set in the SQE len field, then the request will update the user_data of an existing poll request based on the value passed in the off field. This mode is available since 5.13.

  This command works like an asyncpoll(2) and the completion event result is the returned mask of events. For the variants that update user_data or events, the completion result will be similar to OP_POLL_REMOVE.

• OP_POLL_REMOVE - Remove an existing poll request.

  If found, the res field of the struct io_uring_cqe will contain 0. If not found, res will contain -ENOENT, or -EALREADY if the poll request was in the process of completing already.

• OP_SYNC_FILE_RANGE - Issue the equivalent of a sync_file_range(2) on the file descriptor.

  The fd field is the file descriptor to sync, the off field holds the offset in bytes, the len field holds the length in bytes, and the sync_range_flags field holds the flags for the command. See also sync_file_range(2) for the general description of the related system call.

  Available since 5.2.

• OP_SENDMSG - Issue the equivalent of a sendmsg(2) system call.

  fd must be set to the socket file descriptor, addr must contain a pointer to the msghdr structure, and msg_flags holds the flags associated with the system call. See also sendmsg(2) for the general description of the related system call.

  Available since 5.3.

• OP_RECVMSG - Works just like OP_SENDMSG, except for recvmsg(2) instead. See the description of IORING_OP_SENDMSG.

  Available since 5.3.

• OP_TIMEOUT - This command will register a timeout operation.

  The addr field must contain a pointer to a struct timespec64 structure, len must contain 1 to signify one timespec64 structure, timeout_flags may contain TIMEOUT_ABS for an absolute timeout value, or 0 for a relative timeout. off may contain a completion event count. A timeout will trigger a wakeup event on the completion ring for anyone waiting for events. A timeout condition is met when either the specified timeout expires, or the specified number of events have completed. Either condition will trigger the event. If set to 0, completed events are not counted, which effectively acts like a timer. io_uring timeouts use the CLOCK_MONOTONIC clock source. The request will complete with -ETIME if the timeout got completed through expiration of the timer, or 0 if the timeout got completed through requests completing on their own. If the timeout was cancelled before it expired, the request will complete with -ECANCELED.

  Available since 5.4.

  Since 5.15, this command also supports the following modifiers in timeout_flags:

  • TIMEOUT_BOOTTIME: If set, then the clock source used is CLOCK_BOOTTIME instead of CLOCK_MONOTONIC. This clock source differs in that it includes time elapsed if the system was suspend while having a timeout request in-flight.
  • TIMEOUT_REALTIME: If set, then the clock source used is CLOCK_BOOTTIME instead of CLOCK_MONOTONIC.

io_uring_op Enum values:

• OP_NOP - Do not perform any I/O. This is useful for testing the performance of the io_uring implementation itself.
• OP_READV - Vectored read operation, similar to preadv2(2). If the file is not seekable, off must be set to zero.
• OP_WRITEV - Vectored write operation, similar to pwritev2(2). If the file is not seekable, off must be set to zero.
• OP_FSYNC - File sync. See also fsync(2).

  Note that, while I/O is initiated in the order in which it appears inthe submission queue, completions are unordered. For example, an application which places a write I/O followed by an fsync in the submission queue cannot expect the fsync to apply to the write. The two operations execute in parallel, so the fsync may complete before the write is issued to the storage. The same is also true for previously issued writes that have not completed prior to the fsync.

• OP_READ_FIXED - Read from pre-mapped buffers. See register for details on how to setup a context for fixed reads.
• OP_WRITE_FIXED - Write to pre-mapped buffers. See register for details on how to setup a context for fixed writes.
• OP_POLL_ADD - Poll the fd specified in the submission queue entry for the events specified in the poll_events field.

  Unlike poll or epoll without EPOLLONESHOT, by default this interface always works in one shot mode. That is, once the poll operation is completed, it will have to be resubmitted.

  If POLL_ADD_MULTI is set in the SQE len field, then the poll will work in multi shot mode instead. That means it'll repatedly trigger when the requested event becomes true, and hence multiple CQEs can be generated from this single SQE. The CQE flags field will have CQE_F_MORE set on completion if the application should expect further CQE entries from the original request. If this flag isn't set on completion, then the poll request has been terminated and no further events will be generated. This mode is available since 5.13.

  If POLL_UPDATE_EVENTS is set in the SQE len field, then the request will update an existing poll request with the mask of events passed in with this request. The lookup is based on the user_data field of the original SQE submitted, and this values is passed in the addr field of the SQE. This mode is available since 5.13.

  If POLL_UPDATE_USER_DATA is set in the SQE len field, then the request will update the user_data of an existing poll request based on the value passed in the off field. This mode is available since 5.13.

  This command works like an asyncpoll(2) and the completion event result is the returned mask of events. For the variants that update user_data or events, the completion result will be similar to OP_POLL_REMOVE.

• OP_POLL_REMOVE - Remove an existing poll request.

  If found, the res field of the struct io_uring_cqe will contain 0. If not found, res will contain -ENOENT, or -EALREADY if the poll request was in the process of completing already.

• OP_SYNC_FILE_RANGE - Issue the equivalent of a sync_file_range(2) on the file descriptor.

  The fd field is the file descriptor to sync, the off field holds the offset in bytes, the len field holds the length in bytes, and the sync_range_flags field holds the flags for the command. See also sync_file_range(2) for the general description of the related system call.

  Available since 5.2.

• OP_SENDMSG - Issue the equivalent of a sendmsg(2) system call.

  fd must be set to the socket file descriptor, addr must contain a pointer to the msghdr structure, and msg_flags holds the flags associated with the system call. See also sendmsg(2) for the general description of the related system call.

  Available since 5.3.

• OP_RECVMSG - Works just like OP_SENDMSG, except for recvmsg(2) instead. See the description of IORING_OP_SENDMSG.

  Available since 5.3.

• OP_TIMEOUT - This command will register a timeout operation.

  The addr field must contain a pointer to a struct timespec64 structure, len must contain 1 to signify one timespec64 structure, timeout_flags may contain TIMEOUT_ABS for an absolute timeout value, or 0 for a relative timeout. off may contain a completion event count. A timeout will trigger a wakeup event on the completion ring for anyone waiting for events. A timeout condition is met when either the specified timeout expires, or the specified number of events have completed. Either condition will trigger the event. If set to 0, completed events are not counted, which effectively acts like a timer. io_uring timeouts use the CLOCK_MONOTONIC clock source. The request will complete with -ETIME if the timeout got completed through expiration of the timer, or 0 if the timeout got completed through requests completing on their own. If the timeout was cancelled before it expired, the request will complete with -ECANCELED.

  Available since 5.4.

  Since 5.15, this command also supports the following modifiers in timeout_flags:

  • TIMEOUT_BOOTTIME: If set, then the clock source used is CLOCK_BOOTTIME instead of CLOCK_MONOTONIC. This clock source differs in that it includes time elapsed if the system was suspend while having a timeout request in-flight.
  • TIMEOUT_REALTIME: If set, then the clock source used is CLOCK_BOOTTIME instead of CLOCK_MONOTONIC.

io_uring_op Enum values:

• OP_NOP - Do not perform any I/O. This is useful for testing the performance of the io_uring implementation itself.
• OP_READV - Vectored read operation, similar to preadv2(2). If the file is not seekable, off must be set to zero.
• OP_WRITEV - Vectored write operation, similar to pwritev2(2). If the file is not seekable, off must be set to zero.
• OP_FSYNC - File sync. See also fsync(2).

  Note that, while I/O is initiated in the order in which it appears inthe submission queue, completions are unordered. For example, an application which places a write I/O followed by an fsync in the submission queue cannot expect the fsync to apply to the write. The two operations execute in parallel, so the fsync may complete before the write is issued to the storage. The same is also true for previously issued writes that have not completed prior to the fsync.

• OP_READ_FIXED - Read from pre-mapped buffers. See register for details on how to setup a context for fixed reads.
• OP_WRITE_FIXED - Write to pre-mapped buffers. See register for details on how to setup a context for fixed writes.
• OP_POLL_ADD - Poll the fd specified in the submission queue entry for the events specified in the poll_events field.

  Unlike poll or epoll without EPOLLONESHOT, by default this interface always works in one shot mode. That is, once the poll operation is completed, it will have to be resubmitted.

  If POLL_ADD_MULTI is set in the SQE len field, then the poll will work in multi shot mode instead. That means it'll repatedly trigger when the requested event becomes true, and hence multiple CQEs can be generated from this single SQE. The CQE flags field will have CQE_F_MORE set on completion if the application should expect further CQE entries from the original request. If this flag isn't set on completion, then the poll request has been terminated and no further events will be generated. This mode is available since 5.13.

  If POLL_UPDATE_EVENTS is set in the SQE len field, then the request will update an existing poll request with the mask of events passed in with this request. The lookup is based on the user_data field of the original SQE submitted, and this values is passed in the addr field of the SQE. This mode is available since 5.13.

  If POLL_UPDATE_USER_DATA is set in the SQE len field, then the request will update the user_data of an existing poll request based on the value passed in the off field. This mode is available since 5.13.

  This command works like an asyncpoll(2) and the completion event result is the returned mask of events. For the variants that update user_data or events, the completion result will be similar to OP_POLL_REMOVE.

• OP_POLL_REMOVE - Remove an existing poll request.

  If found, the res field of the struct io_uring_cqe will contain 0. If not found, res will contain -ENOENT, or -EALREADY if the poll request was in the process of completing already.

• OP_SYNC_FILE_RANGE - Issue the equivalent of a sync_file_range(2) on the file descriptor.

  The fd field is the file descriptor to sync, the off field holds the offset in bytes, the len field holds the length in bytes, and the sync_range_flags field holds the flags for the command. See also sync_file_range(2) for the general description of the related system call.

  Available since 5.2.

• OP_SENDMSG - Issue the equivalent of a sendmsg(2) system call.

  fd must be set to the socket file descriptor, addr must contain a pointer to the msghdr structure, and msg_flags holds the flags associated with the system call. See also sendmsg(2) for the general description of the related system call.

  Available since 5.3.

• OP_RECVMSG - Works just like OP_SENDMSG, except for recvmsg(2) instead. See the description of IORING_OP_SENDMSG.

  Available since 5.3.

• OP_TIMEOUT - This command will register a timeout operation.

  The addr field must contain a pointer to a struct timespec64 structure, len must contain 1 to signify one timespec64 structure, timeout_flags may contain TIMEOUT_ABS for an absolute timeout value, or 0 for a relative timeout. off may contain a completion event count. A timeout will trigger a wakeup event on the completion ring for anyone waiting for events. A timeout condition is met when either the specified timeout expires, or the specified number of events have completed. Either condition will trigger the event. If set to 0, completed events are not counted, which effectively acts like a timer. io_uring timeouts use the CLOCK_MONOTONIC clock source. The request will complete with -ETIME if the timeout got completed through expiration of the timer, or 0 if the timeout got completed through requests completing on their own. If the timeout was cancelled before it expired, the request will complete with -ECANCELED.

  Available since 5.4.

  Since 5.15, this command also supports the following modifiers in timeout_flags:

  • TIMEOUT_BOOTTIME: If set, then the clock source used is CLOCK_BOOTTIME instead of CLOCK_MONOTONIC. This clock source differs in that it includes time elapsed if the system was suspend while having a timeout request in-flight.
  • TIMEOUT_REALTIME: If set, then the clock source used is CLOCK_BOOTTIME instead of CLOCK_MONOTONIC.

io_uring_op Enum values:

• OP_NOP - Do not perform any I/O. This is useful for testing the performance of the io_uring implementation itself.
• OP_READV - Vectored read operation, similar to preadv2(2). If the file is not seekable, off must be set to zero.
• OP_WRITEV - Vectored write operation, similar to pwritev2(2). If the file is not seekable, off must be set to zero.
• OP_FSYNC - File sync. See also fsync(2).

  Note that, while I/O is initiated in the order in which it appears inthe submission queue, completions are unordered. For example, an application which places a write I/O followed by an fsync in the submission queue cannot expect the fsync to apply to the write. The two operations execute in parallel, so the fsync may complete before the write is issued to the storage. The same is also true for previously issued writes that have not completed prior to the fsync.

• OP_READ_FIXED - Read from pre-mapped buffers. See register for details on how to setup a context for fixed reads.
• OP_WRITE_FIXED - Write to pre-mapped buffers. See register for details on how to setup a context for fixed writes.
• OP_POLL_ADD - Poll the fd specified in the submission queue entry for the events specified in the poll_events field.

  Unlike poll or epoll without EPOLLONESHOT, by default this interface always works in one shot mode. That is, once the poll operation is completed, it will have to be resubmitted.

  If POLL_ADD_MULTI is set in the SQE len field, then the poll will work in multi shot mode instead. That means it'll repatedly trigger when the requested event becomes true, and hence multiple CQEs can be generated from this single SQE. The CQE flags field will have CQE_F_MORE set on completion if the application should expect further CQE entries from the original request. If this flag isn't set on completion, then the poll request has been terminated and no further events will be generated. This mode is available since 5.13.

  If POLL_UPDATE_EVENTS is set in the SQE len field, then the request will update an existing poll request with the mask of events passed in with this request. The lookup is based on the user_data field of the original SQE submitted, and this values is passed in the addr field of the SQE. This mode is available since 5.13.

  If POLL_UPDATE_USER_DATA is set in the SQE len field, then the request will update the user_data of an existing poll request based on the value passed in the off field. This mode is available since 5.13.

  This command works like an asyncpoll(2) and the completion event result is the returned mask of events. For the variants that update user_data or events, the completion result will be similar to OP_POLL_REMOVE.

• OP_POLL_REMOVE - Remove an existing poll request.

  If found, the res field of the struct io_uring_cqe will contain 0. If not found, res will contain -ENOENT, or -EALREADY if the poll request was in the process of completing already.

• OP_SYNC_FILE_RANGE - Issue the equivalent of a sync_file_range(2) on the file descriptor.

  The fd field is the file descriptor to sync, the off field holds the offset in bytes, the len field holds the length in bytes, and the sync_range_flags field holds the flags for the command. See also sync_file_range(2) for the general description of the related system call.

  Available since 5.2.

• OP_SENDMSG - Issue the equivalent of a sendmsg(2) system call.

  fd must be set to the socket file descriptor, addr must contain a pointer to the msghdr structure, and msg_flags holds the flags associated with the system call. See also sendmsg(2) for the general description of the related system call.

  Available since 5.3.

• OP_RECVMSG - Works just like OP_SENDMSG, except for recvmsg(2) instead. See the description of IORING_OP_SENDMSG.

  Available since 5.3.

• OP_TIMEOUT - This command will register a timeout operation.

  The addr field must contain a pointer to a struct timespec64 structure, len must contain 1 to signify one timespec64 structure, timeout_flags may contain TIMEOUT_ABS for an absolute timeout value, or 0 for a relative timeout. off may contain a completion event count. A timeout will trigger a wakeup event on the completion ring for anyone waiting for events. A timeout condition is met when either the specified timeout expires, or the specified number of events have completed. Either condition will trigger the event. If set to 0, completed events are not counted, which effectively acts like a timer. io_uring timeouts use the CLOCK_MONOTONIC clock source. The request will complete with -ETIME if the timeout got completed through expiration of the timer, or 0 if the timeout got completed through requests completing on their own. If the timeout was cancelled before it expired, the request will complete with -ECANCELED.

  Available since 5.4.

  Since 5.15, this command also supports the following modifiers in timeout_flags:

  • TIMEOUT_BOOTTIME: If set, then the clock source used is CLOCK_BOOTTIME instead of CLOCK_MONOTONIC. This clock source differs in that it includes time elapsed if the system was suspend while having a timeout request in-flight.
  • TIMEOUT_REALTIME: If set, then the clock source used is CLOCK_BOOTTIME instead of CLOCK_MONOTONIC.

io_uring_op Enum values:

• OP_NOP - Do not perform any I/O. This is useful for testing the performance of the io_uring implementation itself.
• OP_READV - Vectored read operation, similar to preadv2(2). If the file is not seekable, off must be set to zero.
• OP_WRITEV - Vectored write operation, similar to pwritev2(2). If the file is not seekable, off must be set to zero.
• OP_FSYNC - File sync. See also fsync(2).

  Note that, while I/O is initiated in the order in which it appears inthe submission queue, completions are unordered. For example, an application which places a write I/O followed by an fsync in the submission queue cannot expect the fsync to apply to the write. The two operations execute in parallel, so the fsync may complete before the write is issued to the storage. The same is also true for previously issued writes that have not completed prior to the fsync.

• OP_READ_FIXED - Read from pre-mapped buffers. See register for details on how to setup a context for fixed reads.
• OP_WRITE_FIXED - Write to pre-mapped buffers. See register for details on how to setup a context for fixed writes.
• OP_POLL_ADD - Poll the fd specified in the submission queue entry for the events specified in the poll_events field.

  Unlike poll or epoll without EPOLLONESHOT, by default this interface always works in one shot mode. That is, once the poll operation is completed, it will have to be resubmitted.

  If POLL_ADD_MULTI is set in the SQE len field, then the poll will work in multi shot mode instead. That means it'll repatedly trigger when the requested event becomes true, and hence multiple CQEs can be generated from this single SQE. The CQE flags field will have CQE_F_MORE set on completion if the application should expect further CQE entries from the original request. If this flag isn't set on completion, then the poll request has been terminated and no further events will be generated. This mode is available since 5.13.

  If POLL_UPDATE_EVENTS is set in the SQE len field, then the request will update an existing poll request with the mask of events passed in with this request. The lookup is based on the user_data field of the original SQE submitted, and this values is passed in the addr field of the SQE. This mode is available since 5.13.

  If POLL_UPDATE_USER_DATA is set in the SQE len field, then the request will update the user_data of an existing poll request based on the value passed in the off field. This mode is available since 5.13.

  This command works like an asyncpoll(2) and the completion event result is the returned mask of events. For the variants that update user_data or events, the completion result will be similar to OP_POLL_REMOVE.

• OP_POLL_REMOVE - Remove an existing poll request.

  If found, the res field of the struct io_uring_cqe will contain 0. If not found, res will contain -ENOENT, or -EALREADY if the poll request was in the process of completing already.

• OP_SYNC_FILE_RANGE - Issue the equivalent of a sync_file_range(2) on the file descriptor.

  The fd field is the file descriptor to sync, the off field holds the offset in bytes, the len field holds the length in bytes, and the sync_range_flags field holds the flags for the command. See also sync_file_range(2) for the general description of the related system call.

  Available since 5.2.

• OP_SENDMSG - Issue the equivalent of a sendmsg(2) system call.

  fd must be set to the socket file descriptor, addr must contain a pointer to the msghdr structure, and msg_flags holds the flags associated with the system call. See also sendmsg(2) for the general description of the related system call.

  Available since 5.3.

• OP_RECVMSG - Works just like OP_SENDMSG, except for recvmsg(2) instead. See the description of IORING_OP_SENDMSG.

  Available since 5.3.

• OP_TIMEOUT - This command will register a timeout operation.

  The addr field must contain a pointer to a struct timespec64 structure, len must contain 1 to signify one timespec64 structure, timeout_flags may contain TIMEOUT_ABS for an absolute timeout value, or 0 for a relative timeout. off may contain a completion event count. A timeout will trigger a wakeup event on the completion ring for anyone waiting for events. A timeout condition is met when either the specified timeout expires, or the specified number of events have completed. Either condition will trigger the event. If set to 0, completed events are not counted, which effectively acts like a timer. io_uring timeouts use the CLOCK_MONOTONIC clock source. The request will complete with -ETIME if the timeout got completed through expiration of the timer, or 0 if the timeout got completed through requests completing on their own. If the timeout was cancelled before it expired, the request will complete with -ECANCELED.

  Available since 5.4.

  Since 5.15, this command also supports the following modifiers in timeout_flags:

  • TIMEOUT_BOOTTIME: If set, then the clock source used is CLOCK_BOOTTIME instead of CLOCK_MONOTONIC. This clock source differs in that it includes time elapsed if the system was suspend while having a timeout request in-flight.
  • TIMEOUT_REALTIME: If set, then the clock source used is CLOCK_BOOTTIME instead of CLOCK_MONOTONIC.

io_uring_op Enum values:

• OP_NOP - Do not perform any I/O. This is useful for testing the performance of the io_uring implementation itself.
• OP_READV - Vectored read operation, similar to preadv2(2). If the file is not seekable, off must be set to zero.
• OP_WRITEV - Vectored write operation, similar to pwritev2(2). If the file is not seekable, off must be set to zero.
• OP_FSYNC - File sync. See also fsync(2).

  Note that, while I/O is initiated in the order in which it appears inthe submission queue, completions are unordered. For example, an application which places a write I/O followed by an fsync in the submission queue cannot expect the fsync to apply to the write. The two operations execute in parallel, so the fsync may complete before the write is issued to the storage. The same is also true for previously issued writes that have not completed prior to the fsync.

• OP_READ_FIXED - Read from pre-mapped buffers. See register for details on how to setup a context for fixed reads.
• OP_WRITE_FIXED - Write to pre-mapped buffers. See register for details on how to setup a context for fixed writes.
• OP_POLL_ADD - Poll the fd specified in the submission queue entry for the events specified in the poll_events field.

  Unlike poll or epoll without EPOLLONESHOT, by default this interface always works in one shot mode. That is, once the poll operation is completed, it will have to be resubmitted.

  If POLL_ADD_MULTI is set in the SQE len field, then the poll will work in multi shot mode instead. That means it'll repatedly trigger when the requested event becomes true, and hence multiple CQEs can be generated from this single SQE. The CQE flags field will have CQE_F_MORE set on completion if the application should expect further CQE entries from the original request. If this flag isn't set on completion, then the poll request has been terminated and no further events will be generated. This mode is available since 5.13.

  If POLL_UPDATE_EVENTS is set in the SQE len field, then the request will update an existing poll request with the mask of events passed in with this request. The lookup is based on the user_data field of the original SQE submitted, and this values is passed in the addr field of the SQE. This mode is available since 5.13.

  If POLL_UPDATE_USER_DATA is set in the SQE len field, then the request will update the user_data of an existing poll request based on the value passed in the off field. This mode is available since 5.13.

  This command works like an asyncpoll(2) and the completion event result is the returned mask of events. For the variants that update user_data or events, the completion result will be similar to OP_POLL_REMOVE.

• OP_POLL_REMOVE - Remove an existing poll request.

  If found, the res field of the struct io_uring_cqe will contain 0. If not found, res will contain -ENOENT, or -EALREADY if the poll request was in the process of completing already.

• OP_SYNC_FILE_RANGE - Issue the equivalent of a sync_file_range(2) on the file descriptor.

  The fd field is the file descriptor to sync, the off field holds the offset in bytes, the len field holds the length in bytes, and the sync_range_flags field holds the flags for the command. See also sync_file_range(2) for the general description of the related system call.

  Available since 5.2.

• OP_SENDMSG - Issue the equivalent of a sendmsg(2) system call.

  fd must be set to the socket file descriptor, addr must contain a pointer to the msghdr structure, and msg_flags holds the flags associated with the system call. See also sendmsg(2) for the general description of the related system call.

  Available since 5.3.

• OP_RECVMSG - Works just like OP_SENDMSG, except for recvmsg(2) instead. See the description of IORING_OP_SENDMSG.

  Available since 5.3.

• OP_TIMEOUT - This command will register a timeout operation.

  The addr field must contain a pointer to a struct timespec64 structure, len must contain 1 to signify one timespec64 structure, timeout_flags may contain TIMEOUT_ABS for an absolute timeout value, or 0 for a relative timeout. off may contain a completion event count. A timeout will trigger a wakeup event on the completion ring for anyone waiting for events. A timeout condition is met when either the specified timeout expires, or the specified number of events have completed. Either condition will trigger the event. If set to 0, completed events are not counted, which effectively acts like a timer. io_uring timeouts use the CLOCK_MONOTONIC clock source. The request will complete with -ETIME if the timeout got completed through expiration of the timer, or 0 if the timeout got completed through requests completing on their own. If the timeout was cancelled before it expired, the request will complete with -ECANCELED.

  Available since 5.4.

  Since 5.15, this command also supports the following modifiers in timeout_flags:

  • TIMEOUT_BOOTTIME: If set, then the clock source used is CLOCK_BOOTTIME instead of CLOCK_MONOTONIC. This clock source differs in that it includes time elapsed if the system was suspend while having a timeout request in-flight.
  • TIMEOUT_REALTIME: If set, then the clock source used is CLOCK_BOOTTIME instead of CLOCK_MONOTONIC.

io_uring_op Enum values:

• OP_NOP - Do not perform any I/O. This is useful for testing the performance of the io_uring implementation itself.
• OP_READV - Vectored read operation, similar to preadv2(2). If the file is not seekable, off must be set to zero.
• OP_WRITEV - Vectored write operation, similar to pwritev2(2). If the file is not seekable, off must be set to zero.
• OP_FSYNC - File sync. See also fsync(2).

  Note that, while I/O is initiated in the order in which it appears inthe submission queue, completions are unordered. For example, an application which places a write I/O followed by an fsync in the submission queue cannot expect the fsync to apply to the write. The two operations execute in parallel, so the fsync may complete before the write is issued to the storage. The same is also true for previously issued writes that have not completed prior to the fsync.

• OP_READ_FIXED - Read from pre-mapped buffers. See register for details on how to setup a context for fixed reads.
• OP_WRITE_FIXED - Write to pre-mapped buffers. See register for details on how to setup a context for fixed writes.
• OP_POLL_ADD - Poll the fd specified in the submission queue entry for the events specified in the poll_events field.

  Unlike poll or epoll without EPOLLONESHOT, by default this interface always works in one shot mode. That is, once the poll operation is completed, it will have to be resubmitted.

  If POLL_ADD_MULTI is set in the SQE len field, then the poll will work in multi shot mode instead. That means it'll repatedly trigger when the requested event becomes true, and hence multiple CQEs can be generated from this single SQE. The CQE flags field will have CQE_F_MORE set on completion if the application should expect further CQE entries from the original request. If this flag isn't set on completion, then the poll request has been terminated and no further events will be generated. This mode is available since 5.13.

  If POLL_UPDATE_EVENTS is set in the SQE len field, then the request will update an existing poll request with the mask of events passed in with this request. The lookup is based on the user_data field of the original SQE submitted, and this values is passed in the addr field of the SQE. This mode is available since 5.13.

  If POLL_UPDATE_USER_DATA is set in the SQE len field, then the request will update the user_data of an existing poll request based on the value passed in the off field. This mode is available since 5.13.

  This command works like an asyncpoll(2) and the completion event result is the returned mask of events. For the variants that update user_data or events, the completion result will be similar to OP_POLL_REMOVE.

• OP_POLL_REMOVE - Remove an existing poll request.

  If found, the res field of the struct io_uring_cqe will contain 0. If not found, res will contain -ENOENT, or -EALREADY if the poll request was in the process of completing already.

• OP_SYNC_FILE_RANGE - Issue the equivalent of a sync_file_range(2) on the file descriptor.

  The fd field is the file descriptor to sync, the off field holds the offset in bytes, the len field holds the length in bytes, and the sync_range_flags field holds the flags for the command. See also sync_file_range(2) for the general description of the related system call.

  Available since 5.2.

• OP_SENDMSG - Issue the equivalent of a sendmsg(2) system call.

  fd must be set to the socket file descriptor, addr must contain a pointer to the msghdr structure, and msg_flags holds the flags associated with the system call. See also sendmsg(2) for the general description of the related system call.

  Available since 5.3.

• OP_RECVMSG - Works just like OP_SENDMSG, except for recvmsg(2) instead. See the description of IORING_OP_SENDMSG.

  Available since 5.3.

• OP_TIMEOUT - This command will register a timeout operation.

  The addr field must contain a pointer to a struct timespec64 structure, len must contain 1 to signify one timespec64 structure, timeout_flags may contain TIMEOUT_ABS for an absolute timeout value, or 0 for a relative timeout. off may contain a completion event count. A timeout will trigger a wakeup event on the completion ring for anyone waiting for events. A timeout condition is met when either the specified timeout expires, or the specified number of events have completed. Either condition will trigger the event. If set to 0, completed events are not counted, which effectively acts like a timer. io_uring timeouts use the CLOCK_MONOTONIC clock source. The request will complete with -ETIME if the timeout got completed through expiration of the timer, or 0 if the timeout got completed through requests completing on their own. If the timeout was cancelled before it expired, the request will complete with -ECANCELED.

  Available since 5.4.

  Since 5.15, this command also supports the following modifiers in timeout_flags:

  • TIMEOUT_BOOTTIME: If set, then the clock source used is CLOCK_BOOTTIME instead of CLOCK_MONOTONIC. This clock source differs in that it includes time elapsed if the system was suspend while having a timeout request in-flight.
  • TIMEOUT_REALTIME: If set, then the clock source used is CLOCK_BOOTTIME instead of CLOCK_MONOTONIC.

io_uring_op Enum values:

• OP_NOP - Do not perform any I/O. This is useful for testing the performance of the io_uring implementation itself.
• OP_READV - Vectored read operation, similar to preadv2(2). If the file is not seekable, off must be set to zero.
• OP_WRITEV - Vectored write operation, similar to pwritev2(2). If the file is not seekable, off must be set to zero.
• OP_FSYNC - File sync. See also fsync(2).

  Note that, while I/O is initiated in the order in which it appears inthe submission queue, completions are unordered. For example, an application which places a write I/O followed by an fsync in the submission queue cannot expect the fsync to apply to the write. The two operations execute in parallel, so the fsync may complete before the write is issued to the storage. The same is also true for previously issued writes that have not completed prior to the fsync.

• OP_READ_FIXED - Read from pre-mapped buffers. See register for details on how to setup a context for fixed reads.
• OP_WRITE_FIXED - Write to pre-mapped buffers. See register for details on how to setup a context for fixed writes.
• OP_POLL_ADD - Poll the fd specified in the submission queue entry for the events specified in the poll_events field.

  Unlike poll or epoll without EPOLLONESHOT, by default this interface always works in one shot mode. That is, once the poll operation is completed, it will have to be resubmitted.

  If POLL_ADD_MULTI is set in the SQE len field, then the poll will work in multi shot mode instead. That means it'll repatedly trigger when the requested event becomes true, and hence multiple CQEs can be generated from this single SQE. The CQE flags field will have CQE_F_MORE set on completion if the application should expect further CQE entries from the original request. If this flag isn't set on completion, then the poll request has been terminated and no further events will be generated. This mode is available since 5.13.

  If POLL_UPDATE_EVENTS is set in the SQE len field, then the request will update an existing poll request with the mask of events passed in with this request. The lookup is based on the user_data field of the original SQE submitted, and this values is passed in the addr field of the SQE. This mode is available since 5.13.

  If POLL_UPDATE_USER_DATA is set in the SQE len field, then the request will update the user_data of an existing poll request based on the value passed in the off field. This mode is available since 5.13.

  This command works like an asyncpoll(2) and the completion event result is the returned mask of events. For the variants that update user_data or events, the completion result will be similar to OP_POLL_REMOVE.

• OP_POLL_REMOVE - Remove an existing poll request.

  If found, the res field of the struct io_uring_cqe will contain 0. If not found, res will contain -ENOENT, or -EALREADY if the poll request was in the process of completing already.

• OP_SYNC_FILE_RANGE - Issue the equivalent of a sync_file_range(2) on the file descriptor.

  The fd field is the file descriptor to sync, the off field holds the offset in bytes, the len field holds the length in bytes, and the sync_range_flags field holds the flags for the command. See also sync_file_range(2) for the general description of the related system call.

  Available since 5.2.

• OP_SENDMSG - Issue the equivalent of a sendmsg(2) system call.

  fd must be set to the socket file descriptor, addr must contain a pointer to the msghdr structure, and msg_flags holds the flags associated with the system call. See also sendmsg(2) for the general description of the related system call.

  Available since 5.3.

• OP_RECVMSG - Works just like OP_SENDMSG, except for recvmsg(2) instead. See the description of IORING_OP_SENDMSG.

  Available since 5.3.

• OP_TIMEOUT - This command will register a timeout operation.

  The addr field must contain a pointer to a struct timespec64 structure, len must contain 1 to signify one timespec64 structure, timeout_flags may contain TIMEOUT_ABS for an absolute timeout value, or 0 for a relative timeout. off may contain a completion event count. A timeout will trigger a wakeup event on the completion ring for anyone waiting for events. A timeout condition is met when either the specified timeout expires, or the specified number of events have completed. Either condition will trigger the event. If set to 0, completed events are not counted, which effectively acts like a timer. io_uring timeouts use the CLOCK_MONOTONIC clock source. The request will complete with -ETIME if the timeout got completed through expiration of the timer, or 0 if the timeout got completed through requests completing on their own. If the timeout was cancelled before it expired, the request will complete with -ECANCELED.

  Available since 5.4.

  Since 5.15, this command also supports the following modifiers in timeout_flags:

  • TIMEOUT_BOOTTIME: If set, then the clock source used is CLOCK_BOOTTIME instead of CLOCK_MONOTONIC. This clock source differs in that it includes time elapsed if the system was suspend while having a timeout request in-flight.
  • TIMEOUT_REALTIME: If set, then the clock source used is CLOCK_BOOTTIME instead of CLOCK_MONOTONIC.