Provided by: liburing-dev_2.1-2build1_amd64 bug

NAME

       io_uring_setup - setup a context for performing asynchronous I/O

SYNOPSIS

       #include <linux/io_uring.h>

       int io_uring_setup(u32 entries, struct io_uring_params *p);

DESCRIPTION

       The  io_uring_setup() system call sets up a submission queue (SQ) and completion queue (CQ) with at least
       entries entries, and returns a file descriptor which can be used to perform subsequent operations on  the
       io_uring  instance.   The  submission  and completion queues are shared between userspace and the kernel,
       which eliminates the need to copy data when initiating and completing I/O.

       params is used by the application to pass options to the kernel, and by the kernel to convey  information
       about the ring buffers.

           struct io_uring_params {
               __u32 sq_entries;
               __u32 cq_entries;
               __u32 flags;
               __u32 sq_thread_cpu;
               __u32 sq_thread_idle;
               __u32 features;
               __u32 resv[4];
               struct io_sqring_offsets sq_off;
               struct io_cqring_offsets cq_off;
           };

       The  flags,  sq_thread_cpu, and sq_thread_idle fields are used to configure the io_uring instance.  flags
       is a bit mask of 0 or more of the following values ORed together:

       IORING_SETUP_IOPOLL
              Perform  busy-waiting  for  an  I/O  completion,  as  opposed  to  getting  notifications  via  an
              asynchronous  IRQ  (Interrupt  Request).   The  file system (if any) and block device must support
              polling in order for this to work.  Busy-waiting provides lower latency, but may consume more  CPU
              resources  than interrupt driven I/O.  Currently, this feature is usable only on a file descriptor
              opened using the O_DIRECT flag.  When a read or write  is  submitted  to  a  polled  context,  the
              application  must poll for completions on the CQ ring by calling io_uring_enter(2).  It is illegal
              to mix and match polled and non-polled I/O on an io_uring instance.

       IORING_SETUP_SQPOLL
              When this flag is specified, a kernel thread is created to perform submission queue  polling.   An
              io_uring  instance configured in this way enables an application to issue I/O without ever context
              switching into the kernel.  By using the submission queue to fill in new submission queue  entries
              and  watching  for  completions  on the completion queue, the application can submit and reap I/Os
              without doing a single system call.

              If the kernel thread  is  idle  for  more  than  sq_thread_idle  milliseconds,  it  will  set  the
              IORING_SQ_NEED_WAKEUP  bit  in  the  flags field of the struct io_sq_ring.  When this happens, the
              application must call io_uring_enter(2) to wake the kernel thread.   If  I/O  is  kept  busy,  the
              kernel  thread will never sleep.  An application making use of this feature will need to guard the
              io_uring_enter(2) call with the following code sequence:

                  /*
                   * Ensure that the wakeup flag is read after the tail pointer
                   * has been written. It's important to use memory load acquire
                   * semantics for the flags read, as otherwise the application
                   * and the kernel might not agree on the consistency of the
                   * wakeup flag.
                   */
                  unsigned flags = atomic_load_relaxed(sq_ring->flags);
                  if (flags & IORING_SQ_NEED_WAKEUP)
                      io_uring_enter(fd, 0, 0, IORING_ENTER_SQ_WAKEUP);

              where sq_ring is a submission queue ring setup using the struct io_sqring_offsets described below.

              Before version 5.11 of the Linux kernel, to successfully use this feature,  the  application  must
              register   a   set   of   files   to  be  used  for  IO  through  io_uring_register(2)  using  the
              IORING_REGISTER_FILES opcode. Failure to do so will result in  submitted  IO  being  errored  with
              EBADF.   The  presence  of this feature can be detected by the IORING_FEAT_SQPOLL_NONFIXED feature
              flag.  In version 5.11 and later, it is no longer necessary to register files to use this feature.
              5.11 also allows using this as non-root, if the user has the CAP_SYS_NICE capability.

       IORING_SETUP_SQ_AFF
              If  this flag is specified, then the poll thread will be bound to the cpu set in the sq_thread_cpu
              field of the struct io_uring_params.  This flag is only  meaningful  when  IORING_SETUP_SQPOLL  is
              specified.  When  cgroup  setting  cpuset.cpus  changes  (typically in container environment), the
              bounded cpu set may be changed as well.

       IORING_SETUP_CQSIZE
              Create the completion queue with struct io_uring_params.cq_entries entries.   The  value  must  be
              greater than entries, and may be rounded up to the next power-of-two.

       IORING_SETUP_CLAMP
              If  this  flag  is  specified,  and  if  entries exceeds IORING_MAX_ENTRIES , then entries will be
              clamped at IORING_MAX_ENTRIES .  If the flag IORING_SETUP_SQPOLL is  set,  and  if  the  value  of
              struct  io_uring_params.cq_entries  exceeds  IORING_MAX_CQ_ENTRIES  ,  then  it will be clamped at
              IORING_MAX_CQ_ENTRIES .

       IORING_SETUP_ATTACH_WQ
              This flag should be set in conjunction with struct io_uring_params.wq_fd being set to an  existing
              io_uring  ring  file  descriptor.  When  set,  the  io_uring instance being created will share the
              asynchronous worker thread backend of the specified  io_uring  ring,  rather  than  create  a  new
              separate thread pool.

       IORING_SETUP_R_DISABLED
              If  this  flag  is  specified,  the  io_uring  ring  starts  in  a disabled state.  In this state,
              restrictions can be registered, but submissions are not  allowed.   See  io_uring_register(2)  for
              details on how to enable the ring. Available since 5.10.

       If no flags are specified, the io_uring instance is setup for interrupt driven I/O.  I/O may be submitted
       using io_uring_enter(2) and can be reaped by polling the completion queue.

       The resv array must be initialized to zero.

       features is filled in by the kernel,  which  specifies  various  features  supported  by  current  kernel
       version.

       IORING_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.

       IORING_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.

       IORING_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.

       IORING_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.

       IORING_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 io_uring_enter(2) 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 io_uring_register(2) with IORING_REGISTER_PERSONALITY and
              specify the personality to use in the sqe. Available since kernel 5.6.

       IORING_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.

       IORING_FEAT_POLL_32BITS
              If  this  flag is set, the IORING_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.

       IORING_FEAT_SQPOLL_NONFIXED
              If  this  flag  is set, the IORING_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.

       IORING_FEAT_ENTER_EXT_ARG
              If  this  flag  is  set,  then  the  io_uring_enter(2) 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. The struct layout is as follows:

               struct io_uring_getevents_arg {
                  __u64 sigmask;
                  __u32 sigmask_sz;
                  __u32 pad;
                  __u64 ts;
              };

              and a pointer to this struct must be passed in if IORING_ENTER_EXT_ARG is set in the flags for the
              enter system call. Available since kernel 5.11.

       IORING_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.

       IORING_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.

       The rest of the fields in the struct io_uring_params are  filled  in  by  the  kernel,  and  provide  the
       information  necessary  to memory map the submission queue, completion queue, and the array of submission
       queue entries.  sq_entries specifies the number of submission queue entries allocated.  sq_off  describes
       the offsets of various ring buffer fields:

           struct io_sqring_offsets {
               __u32 head;
               __u32 tail;
               __u32 ring_mask;
               __u32 ring_entries;
               __u32 flags;
               __u32 dropped;
               __u32 array;
               __u32 resv[3];
           };

       Taken  together,  sq_entries  and  sq_off  provide  all  of  the  information necessary for accessing the
       submission queue ring buffer and the submission queue entry array.  The submission queue  can  be  mapped
       with a call like:

           ptr = mmap(0, sq_off.array + sq_entries * sizeof(__u32),
                      PROT_READ|PROT_WRITE, MAP_SHARED|MAP_POPULATE,
                      ring_fd, IORING_OFF_SQ_RING);

       where  sq_off  is  the  io_sqring_offsets  structure,  and  ring_fd  is the file descriptor returned from
       io_uring_setup(2).  The addition of sq_off.array to the length of the region accounts for the  fact  that
       the  ring  located  at the end of the data structure.  As an example, the ring buffer head pointer can be
       accessed by adding sq_off.head to the address returned from mmap(2):

           head = ptr + sq_off.head;

       The flags field is used by the kernel to communicate state information to the application.  Currently, it
       is  used  to inform the application when a call to io_uring_enter(2) is necessary.  See the documentation
       for the IORING_SETUP_SQPOLL flag above.  The dropped member is incremented for  each  invalid  submission
       queue entry encountered in the ring buffer.

       The  head  and  tail  track  the  ring  buffer  state.   The  tail is incremented by the application when
       submitting new I/O, and the head is incremented  by  the  kernel  when  the  I/O  has  been  successfully
       submitted.  Determining the index of the head or tail into the ring is accomplished by applying a mask:

           index = tail & ring_mask;

       The array of submission queue entries is mapped with:

           sqentries = mmap(0, sq_entries * sizeof(struct io_uring_sqe),
                            PROT_READ|PROT_WRITE, MAP_SHARED|MAP_POPULATE,
                            ring_fd, IORING_OFF_SQES);

       The completion queue is described by cq_entries and cq_off shown here:

           struct io_cqring_offsets {
               __u32 head;
               __u32 tail;
               __u32 ring_mask;
               __u32 ring_entries;
               __u32 overflow;
               __u32 cqes;
               __u32 flags;
               __u32 resv[3];
           };

       The  completion  queue  is simpler, since the entries are not separated from the queue itself, and can be
       mapped with:

           ptr = mmap(0, cq_off.cqes + cq_entries * sizeof(struct io_uring_cqe),
                      PROT_READ|PROT_WRITE, MAP_SHARED|MAP_POPULATE, ring_fd,
                      IORING_OFF_CQ_RING);

       Closing the file descriptor returned by io_uring_setup(2) will free all  resources  associated  with  the
       io_uring context.

RETURN VALUE

       io_uring_setup(2)  returns  a  new file descriptor on success.  The application may then provide the file
       descriptor in a subsequent mmap(2)  call  to  map  the  submission  and  completion  queues,  or  to  the
       io_uring_register(2) or io_uring_enter(2) system calls.

       On error, -1 is returned and errno is set appropriately.

ERRORS

       EFAULT params is outside your accessible address space.

       EINVAL The  resv  array  contains  non-zero data, p.flags contains an unsupported flag, entries is out of
              bounds, IORING_SETUP_SQ_AFF was specified, but IORING_SETUP_SQPOLL was not, or IORING_SETUP_CQSIZE
              was specified, but io_uring_params.cq_entries was invalid.

       EMFILE The per-process limit on the number of open file descriptors has been reached (see the description
              of RLIMIT_NOFILE in getrlimit(2)).

       ENFILE The system-wide limit on the total number of open files has been reached.

       ENOMEM Insufficient kernel resources are available.

       EPERM  IORING_SETUP_SQPOLL was specified, but the effective user ID of the caller did not have sufficient
              privileges.

SEE ALSO

       io_uring_register(2), io_uring_enter(2)