[PATCH] block: ublk: check IO buffer based on flag need_get_data

[PATCH] block: ublk: check IO buffer based on flag need_get_data

[Liu Xiaodong]

Currently, uring_cmd with UBLK_IO_FETCH_REQ or
UBLK_IO_COMMIT_AND_FETCH_REQ is always checked whether
userspace server has provided IO buffer even flag
UBLK_F_NEED_GET_DATA is configured.

This is a excessive check. If UBLK_F_NEED_GET_DATA is
configured, FETCH_RQ doesn't need to provide IO buffer;
COMMIT_AND_FETCH_REQ also doesn't need to do that if
the IO type is not READ.

Check ub_cmd->addr together with ublk_need_get_data()
and IO type in ublk_ch_uring_cmd().

With this fix, userspace server doesn't need to preserve
buffers for every ublk_io when flag UBLK_F_NEED_GET_DATA
is configured, in order to save memory.

Signed-off-by: Liu Xiaodong <xiaodong.liu@intel.com>
---
 drivers/block/ublk_drv.c | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/block/ublk_drv.c b/drivers/block/ublk_drv.c
index e54693204630..609137791667 100644
--- a/drivers/block/ublk_drv.c
+++ b/drivers/block/ublk_drv.c
@@ -1203,6 +1203,7 @@ static int ublk_ch_uring_cmd(struct io_uring_cmd *cmd, unsigned int issue_flags)
 	u32 cmd_op = cmd->cmd_op;
 	unsigned tag = ub_cmd->tag;
 	int ret = -EINVAL;
+	struct request *req;
 
 	pr_devel("%s: received: cmd op %d queue %d tag %d result %d\n",
 			__func__, cmd->cmd_op, ub_cmd->q_id, tag,
@@ -1253,8 +1254,8 @@ static int ublk_ch_uring_cmd(struct io_uring_cmd *cmd, unsigned int issue_flags)
 		 */
 		if (io->flags & UBLK_IO_FLAG_OWNED_BY_SRV)
 			goto out;
-		/* FETCH_RQ has to provide IO buffer */
-		if (!ub_cmd->addr)
+		/* FETCH_RQ has to provide IO buffer if NEED GET DATA is not enabled */
+		if (!ub_cmd->addr && !ublk_need_get_data(ubq))
 			goto out;
 		io->cmd = cmd;
 		io->flags |= UBLK_IO_FLAG_ACTIVE;
@@ -1263,8 +1264,12 @@ static int ublk_ch_uring_cmd(struct io_uring_cmd *cmd, unsigned int issue_flags)
 		ublk_mark_io_ready(ub, ubq);
 		break;
 	case UBLK_IO_COMMIT_AND_FETCH_REQ:
-		/* FETCH_RQ has to provide IO buffer */
-		if (!ub_cmd->addr)
+		req = blk_mq_tag_to_rq(ub->tag_set.tags[ub_cmd->q_id], tag);
+		/*
+		 * COMMIT_AND_FETCH_REQ has to provide IO buffer if NEED GET DATA is
+		 * not enabled or it is Read IO.
+		 */
+		if (!ub_cmd->addr && (!ublk_need_get_data(ubq) || req_op(req) == REQ_OP_READ))
 			goto out;
 		if (!(io->flags & UBLK_IO_FLAG_OWNED_BY_SRV))
 			goto out;
-- 
2.14.5

Re: [PATCH] block: ublk: check IO buffer based on flag need_get_data

[Ming Lei]

On Fri, Feb 10, 2023 at 09:13:56AM -0500, Liu Xiaodong wrote:
> Currently, uring_cmd with UBLK_IO_FETCH_REQ or
> UBLK_IO_COMMIT_AND_FETCH_REQ is always checked whether
> userspace server has provided IO buffer even flag
> UBLK_F_NEED_GET_DATA is configured.
> 
> This is a excessive check. If UBLK_F_NEED_GET_DATA is
> configured, FETCH_RQ doesn't need to provide IO buffer;
> COMMIT_AND_FETCH_REQ also doesn't need to do that if
> the IO type is not READ.
> 
> Check ub_cmd->addr together with ublk_need_get_data()
> and IO type in ublk_ch_uring_cmd().
> 
> With this fix, userspace server doesn't need to preserve
> buffers for every ublk_io when flag UBLK_F_NEED_GET_DATA
> is configured, in order to save memory.
> 
> Signed-off-by: Liu Xiaodong <xiaodong.liu@intel.com>

Good catch!

Fixes: c86019ff75c1 ("ublk_drv: add support for UBLK_IO_NEED_GET_DATA")
Reviewed-by: Ming Lei <ming.lei@redhat.com>

Thanks,
Ming

Re: [PATCH] block: ublk: check IO buffer based on flag need_get_data

[Jens Axboe]

On Fri, 10 Feb 2023 09:13:56 -0500, Liu Xiaodong wrote:
> Currently, uring_cmd with UBLK_IO_FETCH_REQ or
> UBLK_IO_COMMIT_AND_FETCH_REQ is always checked whether
> userspace server has provided IO buffer even flag
> UBLK_F_NEED_GET_DATA is configured.
> 
> This is a excessive check. If UBLK_F_NEED_GET_DATA is
> configured, FETCH_RQ doesn't need to provide IO buffer;
> COMMIT_AND_FETCH_REQ also doesn't need to do that if
> the IO type is not READ.
> 
> [...]

Applied, thanks!

[1/1] block: ublk: check IO buffer based on flag need_get_data
      commit: 2f1e07dda1e1310873647abc40bbc49eaf3b10e3

Best regards,
-- 
Jens Axboe