From: Jens Axboe <[email protected]>
To: Kanchan Joshi <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH 2/3] nvme: use separate end IO handler for IOPOLL
Date: Sat, 3 Sep 2022 09:23:02 -0600 [thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <20220903095652.GB10373@test-zns>
On 9/3/22 3:56 AM, Kanchan Joshi wrote:
> On Fri, Sep 02, 2022 at 05:00:51PM -0600, Jens Axboe wrote:
>> Don't need to rely on the cookie or request type, set the right handler
>> based on how we're handling the IO.
>>
>> Signed-off-by: Jens Axboe <[email protected]>
>> ---
>> drivers/nvme/host/ioctl.c | 30 ++++++++++++++++++++++--------
>> 1 file changed, 22 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/nvme/host/ioctl.c b/drivers/nvme/host/ioctl.c
>> index 7756b439a688..f34abe95821e 100644
>> --- a/drivers/nvme/host/ioctl.c
>> +++ b/drivers/nvme/host/ioctl.c
>> @@ -385,25 +385,36 @@ static void nvme_uring_task_cb(struct io_uring_cmd *ioucmd)
>> ????io_uring_cmd_done(ioucmd, status, result);
>> }
>>
>> -static void nvme_uring_cmd_end_io(struct request *req, blk_status_t err)
>> +static void nvme_uring_iopoll_cmd_end_io(struct request *req, blk_status_t err)
>> {
>> ????struct io_uring_cmd *ioucmd = req->end_io_data;
>> ????struct nvme_uring_cmd_pdu *pdu = nvme_uring_cmd_pdu(ioucmd);
>> ????/* extract bio before reusing the same field for request */
>> ????struct bio *bio = pdu->bio;
>> -??? void *cookie = READ_ONCE(ioucmd->cookie);
>>
>> ????pdu->req = req;
>> ????req->bio = bio;
>>
>> ????/*
>> ???? * For iopoll, complete it directly.
>> -???? * Otherwise, move the completion to task work.
>> ???? */
>> -??? if (cookie != NULL && blk_rq_is_poll(req))
>> -??????? nvme_uring_task_cb(ioucmd);
>> -??? else
>> -??????? io_uring_cmd_complete_in_task(ioucmd, nvme_uring_task_cb);
>> +??? nvme_uring_task_cb(ioucmd);
>> +}
>> +
>> +static void nvme_uring_cmd_end_io(struct request *req, blk_status_t err)
>> +{
>> +??? struct io_uring_cmd *ioucmd = req->end_io_data;
>> +??? struct nvme_uring_cmd_pdu *pdu = nvme_uring_cmd_pdu(ioucmd);
>> +??? /* extract bio before reusing the same field for request */
>> +??? struct bio *bio = pdu->bio;
>> +
>> +??? pdu->req = req;
>> +??? req->bio = bio;
>> +
>> +??? /*
>> +???? * Move the completion to task work.
>> +???? */
>> +??? io_uring_cmd_complete_in_task(ioucmd, nvme_uring_task_cb);
>> }
>>
>> static int nvme_uring_cmd_io(struct nvme_ctrl *ctrl, struct nvme_ns *ns,
>> @@ -464,7 +475,10 @@ static int nvme_uring_cmd_io(struct nvme_ctrl *ctrl, struct nvme_ns *ns,
>> ??????????? blk_flags);
>> ????if (IS_ERR(req))
>> ??????? return PTR_ERR(req);
>> -??? req->end_io = nvme_uring_cmd_end_io;
>> +??? if (issue_flags & IO_URING_F_IOPOLL)
>> +??????? req->end_io = nvme_uring_iopoll_cmd_end_io;
>> +??? else
>> +??????? req->end_io = nvme_uring_cmd_end_io;
>
> The polled handler (nvme_uring_iopoll_cmd_end_io) may get called in
> irq context (some swapper/kworker etc.) too. And in that case will it
> be safe to call nvme_uring_task_cb directly. We don't touch the
> user-fields in cmd (thanks to Big CQE) so that part is sorted. But
> there is blk_rq_unmap_user call - can that or anything else inside
> io_req_complete_post() cause trouble.
The unmap might be problematic if the data wasn't mapped. That's a slow
path and unexpected, however. Might be better to just leave the unified
completion path and ensure that nvme_uring_task_cb() checks for polled
as well. I'll give it a quick spin.
--
Jens Axboe
next prev parent reply other threads:[~2022-09-03 15:23 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-02 23:00 [PATCHSET 0/3] Fixups/improvements for iopoll passthrough Jens Axboe
2022-09-02 23:00 ` [PATCH 1/3] io_uring: cleanly separate request types for iopoll Jens Axboe
2022-09-02 23:00 ` [PATCH 2/3] nvme: use separate end IO handler for IOPOLL Jens Axboe
2022-09-03 9:56 ` Kanchan Joshi
2022-09-03 15:23 ` Jens Axboe [this message]
2022-09-02 23:00 ` [PATCH 3/3] fs: add batch and poll flags to the uring_cmd_iopoll() handler Jens Axboe
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] \
/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