diff options
| author | Jens Axboe <axboe@kernel.dk> | 2019-02-10 15:54:30 -0700 |
|---|---|---|
| committer | Jens Axboe <axboe@kernel.dk> | 2019-02-10 15:54:30 -0700 |
| commit | 87ec82f00f58fc7688d8863b8e795c4957516098 (patch) | |
| tree | 207e402b50de83575e65c5d21dcef551ad89103a | |
| parent | f62fdcd85274af3cf7c58725082ad93948b5a5f0 (diff) | |
man/io_uring_enter: mention that SQE entries are always fully consumed
With a recent change to the kernel side, we now fully guarantee that
once io_uring_enter(2) returns that X entries have been submitted, it's
completely safe to reuse tohse entries. This used to not always be the
case, if an SQE had to be punted to async context for submission.
This makes for a more reliable and nicer interface.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
| -rw-r--r-- | man/io_uring_enter.2 | 7 |
1 files changed, 7 insertions, 0 deletions
diff --git a/man/io_uring_enter.2 b/man/io_uring_enter.2 index 6c1f242..92cc77e 100644 --- a/man/io_uring_enter.2 +++ b/man/io_uring_enter.2 @@ -52,6 +52,13 @@ flag in .BR io_uring_setup(2)), as for IRQ driven I/O, the application can just check the completion queue without entering the kernel. +.PP +When the system call returns that a certain amount of SQEs have been +consumed and submitted, it's safe to reuse SQE entries in the ring. This is +true even if the actual IO submission had to be punted to async context, +which means that the SQE may in fact not have been submitted yet. If the +kernel requires later use of a particular SQE entry, it will have made a +private copy of it. .I sig is a pointer to a signal mask (see |