From: Ammar Faizi <[email protected]>
To: Jens Axboe <[email protected]>
Cc: GNU/Weeb Mailing List <[email protected]>,
Ammar Faizi <[email protected]>,
netdev Mailing List <[email protected]>,
Linux Kernel Mailing List <[email protected]>,
io-uring Mailing List <[email protected]>,
Praveen Kumar <[email protected]>,
"David S. Miller" <[email protected]>,
Nugra <[email protected]>, Jakub Kicinski <[email protected]>,
Pavel Begunkov <[email protected]>
Subject: [RFC PATCH v4 0/3] Add sendto(2) and recvfrom(2) support for io_uring
Date: Fri, 7 Jan 2022 07:00:02 +0700 [thread overview]
Message-ID: <[email protected]> (raw)
Hello,
This RFC patchset adds sendto(2) and recvfrom(2) support for io_uring.
It also addresses an issue in the liburing GitHub repository [1].
## Motivations
1) By using `sendto()` and `recvfrom()` we can make the submission
simpler compared to always using `sendmsg()` and `recvmsg()` from
the userspace.
2) There is a historical patch that tried to add the same
functionality, but did not end up being applied. [2]
On Tue, 7 Jul 2020 12:29:18 -0600, Jens Axboe <[email protected]> wrote:
> In a private conversation with the author, a good point was brought
> up that the sendto/recvfrom do not require an allocation of an async
> context, if we need to defer or go async with the request. I think
> that's a major win, to be honest. There are other benefits as well
> (like shorter path), but to me, the async less part is nice and will
> reduce overhead
## Changes summary
There are 3 patches in this series.
PATCH 1/3 renames io_recv to io_recvfrom and io_send to io_sendto.
Note that:
send(sockfd, buf, len, flags);
is equivalent to
sendto(sockfd, buf, len, flags, NULL, 0);
and
recv(sockfd, buf, len, flags);
is equivalent to
recvfrom(sockfd, buf, len, flags, NULL, NULL);
So it is saner to have `send` and `recv` directed to `sendto` and
`recvfrom` instead of the opposite with respect to the name.
PATCH 2/3 makes `move_addr_to_user()` be a non static function. This
function lives in net/socket.c, we need to call this from io_uring
to add `recvfrom()` support for io_uring. Added net files maintainers
to the CC list.
PATCH 3/3 adds `sendto(2)` and `recvfrom(2)` support for io_uring.
Added two new opcodes: IORING_OP_SENDTO and IORING_OP_RECVFROM.
## How to test
This patchset is based on "for-next" branch in Jens' tree commit:
c1537fd063e2f1dbd96d8f68b405a66297ee306f ("Merge branch 'for-5.17/drivers' into for-next")
It is also available in the Git repository at:
https://github.com/ammarfaizi2/linux-block.git ammarfaizi2/linux-block/io_uring-recvfrom-sendto.v4
Test with liburing (added the liburing support, docs, and test program),
the liburing support is based on liburing "master" branch commit:
918d8061ffdfdf253806a1e8e141c71644e678bd ("Remove getdents support")
It is available in the Git repository at:
https://github.com/ammarfaizi2/liburing.git sendto-recvfrom.v2
Please review and comment.
---
RFC v4 (this patchset):
- Rebase the work (sync with "for-next" branch in Jens' tree).
- Remove Tested-by tag from Nugra as we have changes.
- (Address Praveen's comment) Zero `sendto_addr_len` and
`recvfrom_addr_len` on prep when the `req->opcode` is not
`IORING_OP_{SENDTO,RECVFROM}`.
RFC v3:
- Fix build error when CONFIG_NET is undefined for PATCH 1/3. I
tried to fix it in PATCH 3/3, but it should be fixed in PATCH 1/3,
otherwise it breaks the build in PATCH 1/3.
- Added `io_uring_prep_{sendto,recvfrom}` docs to the liburing.
RFC v2:
- Rebase the work, now this patchset is based on commit
bb3294e22482db4b7ec ("Merge branch 'for-5.17/drivers' into
for-next").
- In `io_recvfrom()`, mark the error check of `move_addr_to_user()`
call as unlikely.
- Fix build error when CONFIG_NET is undefined.
- Update liburing test (the branch is still the same, just force
pushed).
- Added Nugra to CC list (tester).
---
RFC v3: https://lore.kernel.org/io-uring/[email protected]/
RFC v2: https://lore.kernel.org/io-uring/[email protected]/
RFC v1: https://lore.kernel.org/io-uring/[email protected]/
Link: https://github.com/axboe/liburing/issues/397 [1]
Link: https://lore.kernel.org/io-uring/[email protected]/ [2]
Signed-off-by: Ammar Faizi <[email protected]>
---
Ammar Faizi (3):
io_uring: Rename `io_{send,recv}` to `io_{sendto,recvfrom}`
net: Make `move_addr_to_user()` be a non static function
io_uring: Add `sendto(2)` and `recvfrom(2)` support
fs/io_uring.c | 94 +++++++++++++++++++++++++++++++----
include/linux/socket.h | 2 +
include/uapi/linux/io_uring.h | 5 +-
net/socket.c | 4 +-
4 files changed, 92 insertions(+), 13 deletions(-)
base-commit: c1537fd063e2f1dbd96d8f68b405a66297ee306f
--
2.32.0
--
GWML mailing list
[email protected]
https://gwml.gnuweeb.org/listinfo/gwml
next reply other threads:[~2022-01-07 0:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-07 0:00 Ammar Faizi [this message]
2022-01-07 0:00 ` [RFC PATCH v4 1/3] io_uring: Rename `io_{send, recv}` to `io_{sendto, recvfrom}` Ammar Faizi
2022-01-07 0:00 ` [RFC PATCH v4 2/3] net: Make `move_addr_to_user()` be a non static function Ammar Faizi
2022-01-07 0:00 ` [RFC PATCH v4 3/3] io_uring: Add `sendto(2)` and `recvfrom(2)` support Ammar Faizi
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] \
[email protected] \
[email protected] \
[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