From: Kanchan Joshi <[email protected]>
To: Pavel Begunkov <[email protected]>
Cc: [email protected], [email protected], [email protected],
[email protected], [email protected],
[email protected], [email protected],
[email protected], Anuj Gupta <[email protected]>
Subject: Re: [PATCH for-next 2/4] io_uring: introduce fixed buffer support for io_uring_cmd
Date: Mon, 22 Aug 2022 17:03:41 +0530 [thread overview]
Message-ID: <20220822113341.GA31599@test-zns> (raw)
In-Reply-To: <[email protected]>
[-- Attachment #1: Type: text/plain, Size: 4098 bytes --]
On Mon, Aug 22, 2022 at 11:58:24AM +0100, Pavel Begunkov wrote:
>On 8/19/22 11:30, Kanchan Joshi wrote:
>>From: Anuj Gupta <[email protected]>
>>
>>Add IORING_OP_URING_CMD_FIXED opcode that enables sending io_uring
>>command with previously registered buffers. User-space passes the buffer
>>index in sqe->buf_index, same as done in read/write variants that uses
>>fixed buffers.
>>
>>Signed-off-by: Anuj Gupta <[email protected]>
>>Signed-off-by: Kanchan Joshi <[email protected]>
>>---
>> include/linux/io_uring.h | 5 ++++-
>> include/uapi/linux/io_uring.h | 1 +
>> io_uring/opdef.c | 10 ++++++++++
>> io_uring/rw.c | 3 ++-
>> io_uring/uring_cmd.c | 18 +++++++++++++++++-
>> 5 files changed, 34 insertions(+), 3 deletions(-)
>>
>>diff --git a/include/linux/io_uring.h b/include/linux/io_uring.h
>>index 60aba10468fc..40961d7c3827 100644
>>--- a/include/linux/io_uring.h
>>+++ b/include/linux/io_uring.h
>>@@ -5,6 +5,8 @@
>> #include <linux/sched.h>
>> #include <linux/xarray.h>
>>+#include<uapi/linux/io_uring.h>
>>+
>> enum io_uring_cmd_flags {
>> IO_URING_F_COMPLETE_DEFER = 1,
>> IO_URING_F_UNLOCKED = 2,
>>@@ -15,6 +17,7 @@ enum io_uring_cmd_flags {
>> IO_URING_F_SQE128 = 4,
>> IO_URING_F_CQE32 = 8,
>> IO_URING_F_IOPOLL = 16,
>>+ IO_URING_F_FIXEDBUFS = 32,
>> };
>> struct io_uring_cmd {
>>@@ -33,7 +36,7 @@ struct io_uring_cmd {
>> #if defined(CONFIG_IO_URING)
>> int io_uring_cmd_import_fixed(u64 ubuf, unsigned long len, int rw,
>>- struct iov_iter *iter, void *ioucmd)
>>+ struct iov_iter *iter, void *ioucmd);
>
>Please try to compile the first patch separately
Indeed, this should have been part of that patch. Thanks.
>> void io_uring_cmd_done(struct io_uring_cmd *cmd, ssize_t ret, ssize_t res2);
>> void io_uring_cmd_complete_in_task(struct io_uring_cmd *ioucmd,
>> void (*task_work_cb)(struct io_uring_cmd *));
>>diff --git a/include/uapi/linux/io_uring.h b/include/uapi/linux/io_uring.h
>>index 1463cfecb56b..80ea35d1ed5c 100644
>>--- a/include/uapi/linux/io_uring.h
>>+++ b/include/uapi/linux/io_uring.h
>>@@ -203,6 +203,7 @@ enum io_uring_op {
>> IORING_OP_SOCKET,
>> IORING_OP_URING_CMD,
>> IORING_OP_SENDZC_NOTIF,
>>+ IORING_OP_URING_CMD_FIXED,
>
>I don't think it should be another opcode, is there any
>control flags we can fit it in?
using sqe->rw_flags could be another way.
But I think that may create bit of disharmony in user-space.
Current choice (IORING_OP_URING_CMD_FIXED) is along the same lines as
IORING_OP_READ/WRITE_FIXED. User-space uses new opcode, and sends the
buffer by filling sqe->buf_index.
So must we take a different way?
>> /* this goes last, obviously */
>> IORING_OP_LAST,
>>diff --git a/io_uring/opdef.c b/io_uring/opdef.c
>>index 9a0df19306fe..7d5731b84c92 100644
>>--- a/io_uring/opdef.c
>>+++ b/io_uring/opdef.c
>>@@ -472,6 +472,16 @@ const struct io_op_def io_op_defs[] = {
>> .issue = io_uring_cmd,
>> .prep_async = io_uring_cmd_prep_async,
>> },
>>+ [IORING_OP_URING_CMD_FIXED] = {
>>+ .needs_file = 1,
>>+ .plug = 1,
>>+ .name = "URING_CMD_FIXED",
>>+ .iopoll = 1,
>>+ .async_size = uring_cmd_pdu_size(1),
>>+ .prep = io_uring_cmd_prep,
>>+ .issue = io_uring_cmd,
>>+ .prep_async = io_uring_cmd_prep_async,
>>+ },
>> [IORING_OP_SENDZC_NOTIF] = {
>> .name = "SENDZC_NOTIF",
>> .needs_file = 1,
>>diff --git a/io_uring/rw.c b/io_uring/rw.c
>>index 1a4fb8a44b9a..3c7b94bffa62 100644
>>--- a/io_uring/rw.c
>>+++ b/io_uring/rw.c
>>@@ -1005,7 +1005,8 @@ int io_do_iopoll(struct io_ring_ctx *ctx, bool force_nonspin)
>> if (READ_ONCE(req->iopoll_completed))
>> break;
>>- if (req->opcode == IORING_OP_URING_CMD) {
>>+ if (req->opcode == IORING_OP_URING_CMD ||
>>+ req->opcode == IORING_OP_URING_CMD_FIXED) {
>
>I don't see the changed chunk upstream
Right, it is on top of iopoll support (plus one more series mentioned in
covered letter). Here is the link -
https://lore.kernel.org/linux-block/[email protected]/
It would be great if you could review that.
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
next prev parent reply other threads:[~2022-08-22 11:43 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20220819104031epcas5p3d485526e1b2b42078ccce7e40a74b7f5@epcas5p3.samsung.com>
2022-08-19 10:30 ` [PATCH for-next 0/4] fixed-buffer for uring-cmd/passthrough Kanchan Joshi
[not found] ` <CGME20220819104036epcas5p2bb4d9b2cccbdfcdb460e085abe7fd1a8@epcas5p2.samsung.com>
2022-08-19 10:30 ` [PATCH for-next 1/4] io_uring: introduce io_uring_cmd_import_fixed Kanchan Joshi
[not found] ` <CGME20220819104038epcas5p265c9385cfd9189d20ebfffeaa4d5efae@epcas5p2.samsung.com>
2022-08-19 10:30 ` [PATCH for-next 2/4] io_uring: introduce fixed buffer support for io_uring_cmd Kanchan Joshi
2022-08-22 10:58 ` Pavel Begunkov
2022-08-22 11:33 ` Kanchan Joshi [this message]
2022-08-25 9:34 ` Pavel Begunkov
2022-08-25 16:02 ` Kanchan Joshi
[not found] ` <CGME20220819104042epcas5p177f384cd4c15918f666c7eacc4dfab4c@epcas5p1.samsung.com>
2022-08-19 10:30 ` [PATCH for-next 3/4] block: add helper to map bvec iterator for passthrough Kanchan Joshi
[not found] ` <CGME20220819104045epcas5p117a9fcb0c3143e877e75e24ceba4f381@epcas5p1.samsung.com>
2022-08-19 10:30 ` [PATCH for-next 4/4] nvme: wire up fixed buffer support for nvme passthrough Kanchan Joshi
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=20220822113341.GA31599@test-zns \
[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