public inbox for io-uring@vger.kernel.org
 help / color / mirror / Atom feed
From: Norman Maurer <norman.maurer@googlemail.com>
To: Jens Axboe <axboe@kernel.dk>
Cc: io-uring@vger.kernel.org, Norman Maurer <norman_maurer@apple.com>
Subject: Re: [PATCH v3] io_uring/net: Allow to do vectorized send
Date: Tue, 29 Jul 2025 07:00:22 -1000	[thread overview]
Message-ID: <4D6BAE51-ECCB-4459-A579-B1419B201249@googlemail.com> (raw)
In-Reply-To: <9cb63fda-89b8-46f6-b316-24550150cf7e@kernel.dk>



> 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 

  reply	other threads:[~2025-07-29 17:00 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2025-07-30 12:21 ` Jens Axboe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D6BAE51-ECCB-4459-A579-B1419B201249@googlemail.com \
    --to=norman.maurer@googlemail.com \
    --cc=axboe@kernel.dk \
    --cc=io-uring@vger.kernel.org \
    --cc=norman_maurer@apple.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox