From: Pavel Begunkov <[email protected]>
To: Stefan Metzmacher <[email protected]>, Jens Axboe <[email protected]>,
[email protected]
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: <[email protected]> (raw)
In-Reply-To: <[email protected]>
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
prev parent 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 \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
/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