* [PATCH v3] io_uring/net: Allow to do vectorized send
@ 2025-07-29 6:59 norman.maurer
2025-07-29 12:15 ` Jens Axboe
2025-07-30 12:21 ` Jens Axboe
0 siblings, 2 replies; 4+ messages in thread
From: norman.maurer @ 2025-07-29 6:59 UTC (permalink / raw)
To: io-uring; +Cc: axboe, Norman Maurer
From: Norman Maurer <norman_maurer@apple.com>
At the moment you have to use sendmsg for vectorized send.
While this works it's suboptimal as it also means you need to
allocate a struct msghdr that needs to be kept alive until a
submission happens. We can remove this limitation by just
allowing to use send directly.
Signed-off-by: Norman Maurer <norman_maurer@apple.com>
---
Changes since v1: Simplify flag check and fix line length of commit message
Changes since v2: Adjust SENDMSG_FLAGS
---
include/uapi/linux/io_uring.h | 4 ++++
io_uring/net.c | 9 ++++++++-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/io_uring.h b/include/uapi/linux/io_uring.h
index b8a0e70ee2fd..6957dc539d83 100644
--- a/include/uapi/linux/io_uring.h
+++ b/include/uapi/linux/io_uring.h
@@ -392,12 +392,16 @@ enum io_uring_op {
* the starting buffer ID in cqe->flags as per
* usual for provided buffer usage. The buffers
* will be contiguous from the starting buffer ID.
+ *
+ * IORING_SEND_VECTORIZED If set, SEND[_ZC] will take a pointer to a io_vec
+ * to allow vectorized send operations.
*/
#define IORING_RECVSEND_POLL_FIRST (1U << 0)
#define IORING_RECV_MULTISHOT (1U << 1)
#define IORING_RECVSEND_FIXED_BUF (1U << 2)
#define IORING_SEND_ZC_REPORT_USAGE (1U << 3)
#define IORING_RECVSEND_BUNDLE (1U << 4)
+#define IORING_SEND_VECTORIZED (1U << 5)
/*
* cqe.res for IORING_CQE_F_NOTIF if
diff --git a/io_uring/net.c b/io_uring/net.c
index ba2d0abea349..3ce5478438f0 100644
--- a/io_uring/net.c
+++ b/io_uring/net.c
@@ -382,6 +382,10 @@ static int io_send_setup(struct io_kiocb *req, const struct io_uring_sqe *sqe)
}
if (req->flags & REQ_F_BUFFER_SELECT)
return 0;
+
+ if (sr->flags & IORING_SEND_VECTORIZED)
+ return io_net_import_vec(req, kmsg, sr->buf, sr->len, ITER_SOURCE);
+
return import_ubuf(ITER_SOURCE, sr->buf, sr->len, &kmsg->msg.msg_iter);
}
@@ -409,7 +413,7 @@ static int io_sendmsg_setup(struct io_kiocb *req, const struct io_uring_sqe *sqe
return io_net_import_vec(req, kmsg, msg.msg_iov, msg.msg_iovlen, ITER_SOURCE);
}
-#define SENDMSG_FLAGS (IORING_RECVSEND_POLL_FIRST | IORING_RECVSEND_BUNDLE)
+#define SENDMSG_FLAGS (IORING_RECVSEND_POLL_FIRST | IORING_RECVSEND_BUNDLE | IORING_SEND_VECTORIZED)
int io_sendmsg_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)
{
@@ -420,6 +424,9 @@ int io_sendmsg_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)
sr->flags = READ_ONCE(sqe->ioprio);
if (sr->flags & ~SENDMSG_FLAGS)
return -EINVAL;
+ if (req->opcode == IORING_OP_SENDMSG && sr->flags & IORING_SEND_VECTORIZED)
+ return -EINVAL;
+
sr->msg_flags = READ_ONCE(sqe->msg_flags) | MSG_NOSIGNAL;
if (sr->msg_flags & MSG_DONTWAIT)
req->flags |= REQ_F_NOWAIT;
--
2.39.5 (Apple Git-154)
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH v3] io_uring/net: Allow to do vectorized send
2025-07-29 6:59 [PATCH v3] io_uring/net: Allow to do vectorized send norman.maurer
@ 2025-07-29 12:15 ` Jens Axboe
2025-07-29 17:00 ` Norman Maurer
2025-07-30 12:21 ` Jens Axboe
1 sibling, 1 reply; 4+ messages in thread
From: Jens Axboe @ 2025-07-29 12:15 UTC (permalink / raw)
To: norman.maurer, io-uring; +Cc: Norman Maurer
On 7/29/25 12:59 AM, norman.maurer@googlemail.com wrote:
> From: Norman Maurer <norman_maurer@apple.com>
>
> At the moment you have to use sendmsg for vectorized send.
> While this works it's suboptimal as it also means you need to
> allocate a struct msghdr that needs to be kept alive until a
> submission happens. We can remove this limitation by just
> allowing to use send directly.
>
> Signed-off-by: Norman Maurer <norman_maurer@apple.com>
> ---
> Changes since v1: Simplify flag check and fix line length of commit message
> Changes since v2: Adjust SENDMSG_FLAGS
>
> ---
> include/uapi/linux/io_uring.h | 4 ++++
> io_uring/net.c | 9 ++++++++-
> 2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/include/uapi/linux/io_uring.h b/include/uapi/linux/io_uring.h
> index b8a0e70ee2fd..6957dc539d83 100644
> --- a/include/uapi/linux/io_uring.h
> +++ b/include/uapi/linux/io_uring.h
> @@ -392,12 +392,16 @@ enum io_uring_op {
> * the starting buffer ID in cqe->flags as per
> * usual for provided buffer usage. The buffers
> * will be contiguous from the starting buffer ID.
> + *
> + * IORING_SEND_VECTORIZED If set, SEND[_ZC] will take a pointer to a io_vec
> + * to allow vectorized send operations.
> */
> #define IORING_RECVSEND_POLL_FIRST (1U << 0)
> #define IORING_RECV_MULTISHOT (1U << 1)
> #define IORING_RECVSEND_FIXED_BUF (1U << 2)
> #define IORING_SEND_ZC_REPORT_USAGE (1U << 3)
> #define IORING_RECVSEND_BUNDLE (1U << 4)
> +#define IORING_SEND_VECTORIZED (1U << 5)
>
> /*
> * cqe.res for IORING_CQE_F_NOTIF if
> diff --git a/io_uring/net.c b/io_uring/net.c
> index ba2d0abea349..3ce5478438f0 100644
> --- a/io_uring/net.c
> +++ b/io_uring/net.c
> @@ -382,6 +382,10 @@ static int io_send_setup(struct io_kiocb *req, const struct io_uring_sqe *sqe)
> }
> if (req->flags & REQ_F_BUFFER_SELECT)
> return 0;
> +
> + if (sr->flags & IORING_SEND_VECTORIZED)
> + return io_net_import_vec(req, kmsg, sr->buf, sr->len, ITER_SOURCE);
> +
> return import_ubuf(ITER_SOURCE, sr->buf, sr->len, &kmsg->msg.msg_iter);
> }
>
> @@ -409,7 +413,7 @@ static int io_sendmsg_setup(struct io_kiocb *req, const struct io_uring_sqe *sqe
> return io_net_import_vec(req, kmsg, msg.msg_iov, msg.msg_iovlen, ITER_SOURCE);
> }
>
> -#define SENDMSG_FLAGS (IORING_RECVSEND_POLL_FIRST | IORING_RECVSEND_BUNDLE)
> +#define SENDMSG_FLAGS (IORING_RECVSEND_POLL_FIRST | IORING_RECVSEND_BUNDLE | IORING_SEND_VECTORIZED)
>
> int io_sendmsg_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)
> {
> @@ -420,6 +424,9 @@ int io_sendmsg_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)
> sr->flags = READ_ONCE(sqe->ioprio);
> if (sr->flags & ~SENDMSG_FLAGS)
> return -EINVAL;
> + if (req->opcode == IORING_OP_SENDMSG && sr->flags & IORING_SEND_VECTORIZED)
> + return -EINVAL;
> +
> sr->msg_flags = READ_ONCE(sqe->msg_flags) | MSG_NOSIGNAL;
> if (sr->msg_flags & MSG_DONTWAIT)
> req->flags |= REQ_F_NOWAIT;
I think this looks simple enough, but after pondering this a bit, I also
think we can just skip the check right above here. OP_SENDMSG is, by
definition, working on IORING_SEND_VECTORIZED data. Hence returning
-EINVAL from that seems a bit redundant. Maybe just delete this hunk?
What do you think?
No need for v3 for that, I can just edit out that hunk with a note. I'll
run some testing today.
--
Jens Axboe
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v3] io_uring/net: Allow to do vectorized send
2025-07-29 12:15 ` Jens Axboe
@ 2025-07-29 17:00 ` Norman Maurer
0 siblings, 0 replies; 4+ messages in thread
From: Norman Maurer @ 2025-07-29 17:00 UTC (permalink / raw)
To: Jens Axboe; +Cc: io-uring, Norman Maurer
> Am 29.07.2025 um 02:15 schrieb Jens Axboe <axboe@kernel.dk>:
>
> On 7/29/25 12:59 AM, norman.maurer@googlemail.com wrote:
>> From: Norman Maurer <norman_maurer@apple.com>
>>
>> At the moment you have to use sendmsg for vectorized send.
>> While this works it's suboptimal as it also means you need to
>> allocate a struct msghdr that needs to be kept alive until a
>> submission happens. We can remove this limitation by just
>> allowing to use send directly.
>>
>> Signed-off-by: Norman Maurer <norman_maurer@apple.com>
>> ---
>> Changes since v1: Simplify flag check and fix line length of commit message
>> Changes since v2: Adjust SENDMSG_FLAGS
>>
>> ---
>> include/uapi/linux/io_uring.h | 4 ++++
>> io_uring/net.c | 9 ++++++++-
>> 2 files changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/uapi/linux/io_uring.h b/include/uapi/linux/io_uring.h
>> index b8a0e70ee2fd..6957dc539d83 100644
>> --- a/include/uapi/linux/io_uring.h
>> +++ b/include/uapi/linux/io_uring.h
>> @@ -392,12 +392,16 @@ enum io_uring_op {
>> * the starting buffer ID in cqe->flags as per
>> * usual for provided buffer usage. The buffers
>> * will be contiguous from the starting buffer ID.
>> + *
>> + * IORING_SEND_VECTORIZED If set, SEND[_ZC] will take a pointer to a io_vec
>> + * to allow vectorized send operations.
>> */
>> #define IORING_RECVSEND_POLL_FIRST (1U << 0)
>> #define IORING_RECV_MULTISHOT (1U << 1)
>> #define IORING_RECVSEND_FIXED_BUF (1U << 2)
>> #define IORING_SEND_ZC_REPORT_USAGE (1U << 3)
>> #define IORING_RECVSEND_BUNDLE (1U << 4)
>> +#define IORING_SEND_VECTORIZED (1U << 5)
>>
>> /*
>> * cqe.res for IORING_CQE_F_NOTIF if
>> diff --git a/io_uring/net.c b/io_uring/net.c
>> index ba2d0abea349..3ce5478438f0 100644
>> --- a/io_uring/net.c
>> +++ b/io_uring/net.c
>> @@ -382,6 +382,10 @@ static int io_send_setup(struct io_kiocb *req, const struct io_uring_sqe *sqe)
>> }
>> if (req->flags & REQ_F_BUFFER_SELECT)
>> return 0;
>> +
>> + if (sr->flags & IORING_SEND_VECTORIZED)
>> + return io_net_import_vec(req, kmsg, sr->buf, sr->len, ITER_SOURCE);
>> +
>> return import_ubuf(ITER_SOURCE, sr->buf, sr->len, &kmsg->msg.msg_iter);
>> }
>>
>> @@ -409,7 +413,7 @@ static int io_sendmsg_setup(struct io_kiocb *req, const struct io_uring_sqe *sqe
>> return io_net_import_vec(req, kmsg, msg.msg_iov, msg.msg_iovlen, ITER_SOURCE);
>> }
>>
>> -#define SENDMSG_FLAGS (IORING_RECVSEND_POLL_FIRST | IORING_RECVSEND_BUNDLE)
>> +#define SENDMSG_FLAGS (IORING_RECVSEND_POLL_FIRST | IORING_RECVSEND_BUNDLE | IORING_SEND_VECTORIZED)
>>
>> int io_sendmsg_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)
>> {
>> @@ -420,6 +424,9 @@ int io_sendmsg_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)
>> sr->flags = READ_ONCE(sqe->ioprio);
>> if (sr->flags & ~SENDMSG_FLAGS)
>> return -EINVAL;
>> + if (req->opcode == IORING_OP_SENDMSG && sr->flags & IORING_SEND_VECTORIZED)
>> + return -EINVAL;
>> +
>> sr->msg_flags = READ_ONCE(sqe->msg_flags) | MSG_NOSIGNAL;
>> if (sr->msg_flags & MSG_DONTWAIT)
>> req->flags |= REQ_F_NOWAIT;
>
> I think this looks simple enough, but after pondering this a bit, I also
> think we can just skip the check right above here. OP_SENDMSG is, by
> definition, working on IORING_SEND_VECTORIZED data. Hence returning
> -EINVAL from that seems a bit redundant. Maybe just delete this hunk?
> What do you think?
Works for me
>
> No need for v3 for that, I can just edit out that hunk with a note. I'll
> run some testing today.
Thanks! Looking forward to hear back on the results
>
> --
> Jens Axboe
Bye
Norman
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v3] io_uring/net: Allow to do vectorized send
2025-07-29 6:59 [PATCH v3] io_uring/net: Allow to do vectorized send norman.maurer
2025-07-29 12:15 ` Jens Axboe
@ 2025-07-30 12:21 ` Jens Axboe
1 sibling, 0 replies; 4+ messages in thread
From: Jens Axboe @ 2025-07-30 12:21 UTC (permalink / raw)
To: io-uring, norman.maurer; +Cc: Norman Maurer
On Mon, 28 Jul 2025 20:59:53 -1000, norman.maurer@googlemail.com wrote:
> At the moment you have to use sendmsg for vectorized send.
> While this works it's suboptimal as it also means you need to
> allocate a struct msghdr that needs to be kept alive until a
> submission happens. We can remove this limitation by just
> allowing to use send directly.
>
>
> [...]
Applied, thanks!
[1/1] io_uring/net: Allow to do vectorized send
commit: 423a72545c7b59f304781bf38050d537b6a7ed5e
Best regards,
--
Jens Axboe
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2025-07-30 12:21 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-07-29 6:59 [PATCH v3] io_uring/net: Allow to do vectorized send norman.maurer
2025-07-29 12:15 ` Jens Axboe
2025-07-29 17:00 ` Norman Maurer
2025-07-30 12:21 ` Jens Axboe
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox