[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CADUfDZq88mkARUOx-RQw72dwkTc2EB+0KiBtC6BL66e4pgiZxw@mail.gmail.com>
Date: Fri, 31 Oct 2025 11:29:38 -0700
From: Caleb Sander Mateos <csander@...estorage.com>
To: Christoph Hellwig <hch@....de>
Cc: Jens Axboe <axboe@...nel.dk>, Miklos Szeredi <miklos@...redi.hu>, Ming Lei <ming.lei@...hat.com>,
Keith Busch <kbusch@...nel.org>, Sagi Grimberg <sagi@...mberg.me>, Chris Mason <clm@...com>,
David Sterba <dsterba@...e.com>, io-uring@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-block@...r.kernel.org, linux-nvme@...ts.infradead.org,
linux-btrfs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 4/4] io_uring/uring_cmd: avoid double indirect call in
task work dispatch
On Mon, Oct 27, 2025 at 12:51 AM Christoph Hellwig <hch@....de> wrote:
>
> > +static void blk_cmd_complete(struct io_tw_req tw_req, io_tw_token_t tw)
> > {
> > + unsigned int issue_flags = IO_URING_CMD_TASK_WORK_ISSUE_FLAGS;
>
> In most of these ioctl handlers issue_flags only has a single user,
> so you might as well pass it directly.
Sure, happy to get rid of the intermediate variable in places where
issue_flags is only referenced once.
>
> In fact asm most external callers of io_uring_cmd_done pass that, would
> a helper that just harcodes it make sense and then maybe switch the
> special cases to use __io_uring_cmd_done directly?
While issue_flags is mainly used to pass to io_uring_cmd_done(), there
are some other uses too. For example, ublk_cmd_tw_cb() and
ublk_cmd_list_tw_cb() pass it to io_buffer_register_bvec() via
ublk_dispatch_req(), ublk_prep_auto_buf_reg(), and
ublk_auto_buf_reg(). Since uring_cmd implementations can perform
arbitrary work in task work context, I think it makes sense to keep
IO_URING_CMD_TASK_WORK_ISSUE_FLAG so it can be used wherever it's
required.
Best,
Caleb
Powered by blists - more mailing lists