aboutsummaryrefslogtreecommitdiff
path: root/man/io_uring_prep_recvmsg.3
diff options
context:
space:
mode:
Diffstat (limited to 'man/io_uring_prep_recvmsg.3')
-rw-r--r--man/io_uring_prep_recvmsg.394
1 files changed, 94 insertions, 0 deletions
diff --git a/man/io_uring_prep_recvmsg.3 b/man/io_uring_prep_recvmsg.3
new file mode 100644
index 0000000..8c49411
--- /dev/null
+++ b/man/io_uring_prep_recvmsg.3
@@ -0,0 +1,94 @@
+.\" Copyright (C) 2022 Jens Axboe <axboe@kernel.dk>
+.\"
+.\" SPDX-License-Identifier: LGPL-2.0-or-later
+.\"
+.TH io_uring_prep_recvmsg 3 "March 12, 2022" "liburing-2.2" "liburing Manual"
+.SH NAME
+io_uring_prep_recvmsg \- prepare a recvmsg request
+.SH SYNOPSIS
+.nf
+.B #include <sys/types.h>
+.B #include <sys/socket.h>
+.B #include <liburing.h>
+.PP
+.BI "void io_uring_prep_recvmsg(struct io_uring_sqe *" sqe ","
+.BI " int " fd ","
+.BI " struct msghdr *" msg ","
+.BI " unsigned " flags ");"
+.fi
+.SH DESCRIPTION
+.PP
+The
+.BR io_uring_prep_recvmsg (3)
+function prepares a recvmsg request. The submission queue entry
+.I sqe
+is setup to use the file descriptor
+.I fd
+to start receiving the data indicated by
+.I msg
+with the
+.BR recvmsg (2)
+defined flags in the
+.I flags
+argument.
+
+This function prepares an async
+.BR recvmsg (2)
+request. See that man page for details on the arguments specified to this
+prep helper.
+
+After calling this function, additional io_uring internal modifier flags
+may be set in the SQE
+.I off
+field. The following flags are supported:
+.TP
+.B IORING_RECVSEND_POLL_FIRST
+If set, io_uring will assume the socket is currently empty and attempting to
+receive data will be unsuccessful. For this case, io_uring will arm internal
+poll and trigger a receive of the data when the socket has data to be read.
+This initial receive attempt can be wasteful for the case where the socket
+is expected to be empty, setting this flag will bypass the initial receive
+attempt and go straight to arming poll. If poll does indicate that data is
+ready to be received, the operation will proceed.
+
+Can be used with the CQE
+.B IORING_CQE_F_SOCK_NONEMPTY
+flag, which io_uring will set on CQEs after a
+.BR recv (2)
+or
+.BR recvmsg (2)
+operation. If set, the socket still had data to be read after the operation
+completed. Both these flags are available since 5.19.
+.P
+
+.SH RETURN VALUE
+None
+.SH ERRORS
+The CQE
+.I res
+field will contain the result of the operation. See the related man page for
+details on possible values. Note that where synchronous system calls will return
+.B -1
+on failure and set
+.I errno
+to the actual error value, io_uring never uses
+.IR errno .
+Instead it returns the negated
+.I errno
+directly in the CQE
+.I res
+field.
+.SH NOTES
+As with any request that passes in data in a struct, that data must remain
+valid until the request has been successfully submitted. It need not remain
+valid until completion. Once a request has been submitted, the in-kernel
+state is stable. Very early kernels (5.4 and earlier) required state to be
+stable until the completion occurred. Applications can test for this
+behavior by inspecting the
+.B IORING_FEAT_SUBMIT_STABLE
+flag passed back from
+.BR io_uring_queue_init_params (3).
+.SH SEE ALSO
+.BR io_uring_get_sqe (3),
+.BR io_uring_submit (3),
+.BR recvmsg (2)