All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Begunkov <asml.silence@gmail.com>
To: Stefan Metzmacher <metze@samba.org>, Jens Axboe <axboe@kernel.dk>,
	io-uring@vger.kernel.org
Subject: Re: [PATCH 1/1] io_uring/net: send retry for zerocopy
Date: Mon, 15 Aug 2022 10:14:59 +0100	[thread overview]
Message-ID: <c9ab79bc-3e2c-635e-3991-2aa659166d96@gmail.com> (raw)
In-Reply-To: <6e523a67-96ce-e67e-e07d-3b63a86e5e3f@samba.org>

On 8/14/22 15:48, Stefan Metzmacher wrote:
> Am 14.08.22 um 16:13 schrieb Jens Axboe:
>> On 8/14/22 8:11 AM, Stefan Metzmacher wrote:
>>>>> Don't we need a prep_async function and/or something like
>>>>> io_setup_async_msg() here to handle address?

>>> This has support for sockaddr address compared to io_send(),
>>> if the caller need to keep io_sendzc->addr valid until the qce arrived,
>>> then we need to clearly document that, as that doesn't match the common practice
>>> of other opcodes. Currently everything but data buffers can go after the sqe is
>>> submitted.

Yes, can be this way if we agree it's preferable.

>> Good point, it's not just the 'from' address. Pavel?

It is

> It's basically dest_addr from:
> 
>         ssize_t sendto(int sockfd, const void *buf, size_t len, int flags,
>                        const struct sockaddr *dest_addr, socklen_t addrlen);
> 
> It's not used in most cases, but for non-connected udp sockets you need it.
> 
> Maybe the fixed io_op_def.async_size could be changed to something that only
> allocated the async data if needed. Maybe the prep_async() hook could to the allocation
> itself if needed.

It's details, easy to implement, e.g. we can just decouple the
allocation from async preparation. I'll give it a try after sending
other small zc API changes

-- 
Pavel Begunkov

      reply	other threads:[~2022-08-15  9:18 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-04 14:15 [PATCH 1/1] io_uring/net: send retry for zerocopy Pavel Begunkov
2022-08-04 14:53 ` Jens Axboe
2022-08-14  9:31 ` Stefan Metzmacher
2022-08-14 14:05   ` Jens Axboe
2022-08-14 14:11     ` Stefan Metzmacher
2022-08-14 14:13       ` Jens Axboe
2022-08-14 14:48         ` Stefan Metzmacher
2022-08-15  9:14           ` Pavel Begunkov [this message]

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=c9ab79bc-3e2c-635e-3991-2aa659166d96@gmail.com \
    --to=asml.silence@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=io-uring@vger.kernel.org \
    --cc=metze@samba.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.