From: Jens Axboe <[email protected]>
To: Christoph Hellwig <[email protected]>
Cc: Kanchan Joshi <[email protected]>,
[email protected], [email protected],
[email protected], [email protected], [email protected],
[email protected], [email protected], [email protected],
[email protected]
Subject: Re: [PATCH v4 4/5] nvme: wire-up uring-cmd support for io-passthru on char-device.
Date: Sat, 7 May 2022 06:53:30 -0600 [thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
On 5/6/22 11:03 PM, Christoph Hellwig wrote:
> Getting back to this after a good night's worth of sleep:
>
> On Fri, May 06, 2022 at 08:57:53AM -0600, Jens Axboe wrote:
>>> Just add this:
>>>
>>> "Add a small helper to act as the counterpart to nvme_add_user_metadata."
>>>
>>> with my signoff:
>>>
>>> Signed-off-by: Christoph Hellwig <[email protected]>
>>
>> Both done, thanks.
>
> I think we're much better of folding "nvme: add nvme_finish_user_metadata
> helper" into "nvme: refactor nvme_submit_user_cmd()" as the first basically
> just redos the split done in the first patch in a more fine grained way
> to allow sharing some of the metadata end I/O code with the uring path,
> and basically only touches code changes in the first patch again.
Yes good point, I've folded the two.
>>>> I did not do your async_size changes, I think you're jetlagged eyes
>>>> missed that this isn't a sizeof thing on a flexible array, it's just the
>>>> offset of it. Hence for non-sqe128, the the async size is io_uring_sqe -
>>>> offsetof where pdu starts, and so forth.
>>>
>>> Hmm, this still seems a bit odd to me. So without sqe128 you don't even
>>> get the cmd data that would fit into the 64-bit SQE?
>>
>> You do. Without sqe128, you get sizeof(sqe) - offsetof(cmd) == 16 bytes.
>> With, you get 16 + 64, 80.
>
> Can we please get a little documented helper that does this instead of
> the two open coded places?
How about we just add a comment? We use it in two spots, but one has
knowledge of the sqe64 vs sqe128 state, the other one does not. Hence
not sure how best to add a helper for this. One also must be a compile
time constant. Best I can think of is the below. Not the prettiest, but
it does keep it in one spot and with a single comment rather than in two
spots.
diff --git a/fs/io_uring.c b/fs/io_uring.c
index 1860c50f7f8e..0a9b0fde55af 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -1044,6 +1044,14 @@ struct io_cancel_data {
int seq;
};
+/*
+ * The URING_CMD payload starts at 'cmd' in the first sqe, and continues into
+ * the following sqe if SQE128 is used.
+ */
+#define uring_cmd_pdu_size(is_sqe128) \
+ ((1 + !!(is_sqe128)) * sizeof(struct io_uring_sqe) - \
+ offsetof(struct io_uring_sqe, cmd))
+
struct io_op_def {
/* needs req->file assigned */
unsigned needs_file : 1;
@@ -1286,8 +1294,7 @@ static const struct io_op_def io_op_defs[] = {
[IORING_OP_URING_CMD] = {
.needs_file = 1,
.plug = 1,
- .async_size = 2 * sizeof(struct io_uring_sqe) -
- offsetof(struct io_uring_sqe, cmd),
+ .async_size = uring_cmd_pdu_size(1),
},
};
@@ -4947,11 +4954,9 @@ EXPORT_SYMBOL_GPL(io_uring_cmd_done);
static int io_uring_cmd_prep_async(struct io_kiocb *req)
{
- size_t cmd_size = sizeof(struct io_uring_sqe) -
- offsetof(struct io_uring_sqe, cmd);
+ size_t cmd_size;
- if (req->ctx->flags & IORING_SETUP_SQE128)
- cmd_size += sizeof(struct io_uring_sqe);
+ cmd_size = uring_cmd_pdu_size(req->ctx->flags & IORING_SETUP_SQE128);
memcpy(req->async_data, req->uring_cmd.cmd, cmd_size);
return 0;
--
Jens Axboe
next prev parent reply other threads:[~2022-05-07 12:53 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20220505061142epcas5p2c943572766bfd5088138fe0f7873c96c@epcas5p2.samsung.com>
2022-05-05 6:06 ` [PATCH v4 0/5] io_uring passthrough for nvme Kanchan Joshi
[not found] ` <CGME20220505061144epcas5p3821a9516dad2b5eff5a25c56dbe164df@epcas5p3.samsung.com>
2022-05-05 6:06 ` [PATCH v4 1/5] fs,io_uring: add infrastructure for uring-cmd Kanchan Joshi
2022-05-05 12:52 ` Jens Axboe
2022-05-05 13:48 ` Ming Lei
2022-05-05 13:54 ` Jens Axboe
2022-05-05 13:29 ` Christoph Hellwig
2022-05-05 16:17 ` Jens Axboe
2022-05-05 17:04 ` Jens Axboe
2022-05-06 7:12 ` Kanchan Joshi
2022-05-10 14:23 ` Kanchan Joshi
2022-05-10 14:35 ` Jens Axboe
[not found] ` <CGME20220505061146epcas5p3919c48d58d353a62a5858ee10ad162a0@epcas5p3.samsung.com>
2022-05-05 6:06 ` [PATCH v4 2/5] block: wire-up support for passthrough plugging Kanchan Joshi
2022-05-05 14:21 ` Ming Lei
[not found] ` <CGME20220505061148epcas5p188618b5b15a95cbe48c8c1559a18c994@epcas5p1.samsung.com>
2022-05-05 6:06 ` [PATCH v4 3/5] nvme: refactor nvme_submit_user_cmd() Kanchan Joshi
2022-05-05 13:30 ` Christoph Hellwig
2022-05-05 18:37 ` Clay Mayers
2022-05-05 19:03 ` Jens Axboe
2022-05-05 19:11 ` Jens Axboe
2022-05-05 19:30 ` Clay Mayers
2022-05-05 19:31 ` Jens Axboe
2022-05-05 19:50 ` hch
2022-05-05 20:44 ` Jens Axboe
2022-05-06 5:56 ` hch
[not found] ` <CGME20220505061150epcas5p2b60880c541a4b2f144c348834c7cbf0b@epcas5p2.samsung.com>
2022-05-05 6:06 ` [PATCH v4 4/5] nvme: wire-up uring-cmd support for io-passthru on char-device Kanchan Joshi
2022-05-05 13:33 ` Christoph Hellwig
2022-05-05 13:38 ` Jens Axboe
2022-05-05 13:42 ` Christoph Hellwig
2022-05-05 13:50 ` Jens Axboe
2022-05-05 17:23 ` Jens Axboe
2022-05-06 8:28 ` Christoph Hellwig
2022-05-06 13:37 ` Jens Axboe
2022-05-06 14:50 ` Christoph Hellwig
2022-05-06 14:57 ` Jens Axboe
2022-05-07 5:03 ` Christoph Hellwig
2022-05-07 12:53 ` Jens Axboe [this message]
2022-05-09 6:00 ` Christoph Hellwig
2022-05-09 12:52 ` Jens Axboe
[not found] ` <CGME20220505061151epcas5p2523dc661a0daf3e6185dee771eade393@epcas5p2.samsung.com>
2022-05-05 6:06 ` [PATCH v4 5/5] nvme: add vectored-io support for uring-cmd Kanchan Joshi
2022-05-05 18:20 ` [PATCH v4 0/5] io_uring passthrough for nvme Jens Axboe
2022-05-05 18:29 ` Jens Axboe
2022-05-06 6:42 ` Kanchan Joshi
2022-05-06 13:14 ` Jens Axboe
2022-05-10 7:20 ` Christoph Hellwig
2022-05-10 12:29 ` Jens Axboe
2022-05-10 14:21 ` 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 \
[email protected] \
[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