public inbox for fio@vger.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Vincent Fu <vincentfu@gmail.com>,
	anuj1072538@gmail.com, hch@infradead.org, joshi.k@samsung.com,
	anuj20.g@samsung.com, fio@vger.kernel.org
Cc: Vincent Fu <vincent.fu@samsung.com>
Subject: Re: [PATCH 1/2] engines/io_uring: support r/w with metadata
Date: Wed, 23 Jul 2025 11:23:32 -0600	[thread overview]
Message-ID: <15cb4581-7067-40fa-9a1b-8883c9993d2c@kernel.dk> (raw)
In-Reply-To: <67829b031f25595387d7dce10fa0355d85fbebae.1753282479.git.vincent.fu@samsung.com>

On 7/23/25 11:04 AM, Vincent Fu wrote:
> @@ -436,6 +502,27 @@ static int fio_ioring_prep(struct thread_data *td, struct io_u *io_u)
>  				sqe->len = 1;
>  			}
>  		}
> +		if (o->md_per_io_size) {
> +			struct io_uring_attr_pi *pi_attr = io_u->pi_attr;
> +			struct nvme_data *data = FILE_ENG_DATA(io_u->file);
> +
> +			sqe->attr_type_mask = IORING_RW_ATTR_FLAG_PI;
> +			sqe->attr_ptr = (__u64)(uintptr_t)pi_attr;
> +			pi_attr->addr = (__u64)(uintptr_t)io_u->mmap_data;
> +			pi_attr->len = o->md_per_io_size;
> +			pi_attr->app_tag = o->apptag;
> +			pi_attr->flags = 0;
> +			if (strstr(o->pi_chk, "GUARD") != NULL)
> +				pi_attr->flags |= IO_INTEGRITY_CHK_GUARD;
> +			if (strstr(o->pi_chk, "REFTAG") != NULL) {
> +				__u64 slba = get_slba(data, io_u->offset);
> +
> +				pi_attr->flags |= IO_INTEGRITY_CHK_REFTAG;
> +				pi_attr->seed = (__u32)slba;
> +			}
> +			if (strstr(o->pi_chk, "APPTAG") != NULL)
> +				pi_attr->flags |= IO_INTEGRITY_CHK_APPTAG;
> +		}

I'd move these out-of-line whenever possible. It both improves
readability, but also conveys that this isn't necessarily the normal/hot
path.

> @@ -590,6 +678,19 @@ static struct io_u *fio_ioring_event(struct thread_data *td, int event)
>  			io_u->error = -cqe->res;
>  		else
>  			io_u->resid = io_u->xfer_buflen - cqe->res;
> +		return io_u;
> +	}
> +
> +	if (o->md_per_io_size) {
> +		struct nvme_data *data;
> +		int ret;
> +
> +		data = FILE_ENG_DATA(io_u->file);
> +		if (data->pi_type && (io_u->ddir == DDIR_READ) && !o->pi_act) {
> +			ret = fio_nvme_pi_verify(data, io_u);
> +			if (ret)
> +				io_u->error = ret;
> +		}
>  	}

Ditto

> +	if (!strcmp(td->io_ops->name, "io_uring") && o->md_per_io_size) {
> +		struct nvme_data *data = FILE_ENG_DATA(io_u->file);
> +		struct nvme_cmd_ext_io_opts ext_opts = {0};
> +
> +		if (data->pi_type) {
> +			if (o->pi_act)
> +				ext_opts.io_flags |= NVME_IO_PRINFO_PRACT;
> +
> +			ext_opts.io_flags |= o->prchk;
> +			ext_opts.apptag = o->apptag;
> +			ext_opts.apptag_mask = o->apptag_mask;
> +		}
> +		fio_nvme_generate_guard(io_u, &ext_opts);
> +	}

Ehh a strcmp() in the hot path?! First of all, that's a big no-no.
Secondly, if this really was required, you'd add something to put that
strcmp() in the slow path and flag it. Lastly, thankfully this should be
much better as:

	if (td->io_ops == &ioengine_uring ...)

instead.

> @@ -1347,12 +1464,20 @@ static int fio_ioring_init(struct thread_data *td)
>  	/* io_u index */
>  	ld->io_u_index = calloc(td->o.iodepth, sizeof(struct io_u *));
>  
> +	if (!strcmp(td->io_ops->name, "io_uring") && o->md_per_io_size) {
> +		if (o->apptag_mask != 0xffff) {
> +			log_err("fio: io_uring with metadata requires an apptag_mask of 0xffff\n");
> +			return 1;
> +		}
> +	}

Same, though this is at least slow path. But people copy-paste wonky
code like that all the time...

>  	 * metadata buffer for nvme command.
>  	 * We are only supporting iomem=malloc / mem=malloc as of now.
>  	 */
> -	if (!strcmp(td->io_ops->name, "io_uring_cmd") &&
> -	    (o->cmd_type == FIO_URING_CMD_NVME) && o->md_per_io_size) {
> +	if ((!strcmp(td->io_ops->name, "io_uring_cmd") &&
> +	    (o->cmd_type == FIO_URING_CMD_NVME) && o->md_per_io_size) ||
> +	    (!strcmp(td->io_ops->name, "io_uring") && o->md_per_io_size)) {
>  		md_size = (unsigned long long) o->md_per_io_size
>  				* (unsigned long long) td->o.iodepth;
>  		md_size += page_mask + td->o.mem_align;

And I'm starting to see where this is coming from. If you are so
inclined, please do a cleanup patch first getting rid of these strcmp()
calls.

>  static int fio_ioring_open_file(struct thread_data *td, struct fio_file *f)
>  {
>  	struct ioring_data *ld = td->io_ops_data;
>  	struct ioring_options *o = td->eo;
>  
> +	if (o->md_per_io_size) {
> +		struct nvme_data *data = NULL;
> +		__u64 nlba = 0;
> +		int ret;
> +
> +		data = FILE_ENG_DATA(f);
> +		if (data == NULL) {
> +			data = calloc(1, sizeof(struct nvme_data));
> +			ret = fio_get_pi_info(f, &nlba, o->pi_act, data);
> +			if (ret) {
> +				free(data);
> +				return ret;
> +			}
> +
> +			FILE_SET_ENG_DATA(f, data);
> +		}
> +	}

Out of line please...

> diff --git a/engines/nvme.c b/engines/nvme.c
> index 37a31e2f..4b3d3860 100644
> --- a/engines/nvme.c
> +++ b/engines/nvme.c
> @@ -8,22 +8,6 @@
>  #include "../crc/crc-t10dif.h"
>  #include "../crc/crc64.h"
>  
> -static inline __u64 get_slba(struct nvme_data *data, __u64 offset)
> -{
> -	if (data->lba_ext)
> -		return offset / data->lba_ext;
> -
> -	return offset >> data->lba_shift;
> -}
> -
> -static inline __u32 get_nlb(struct nvme_data *data, __u64 len)
> -{
> -	if (data->lba_ext)
> -		return len / data->lba_ext - 1;
> -
> -	return (len >> data->lba_shift) - 1;
> -}
> -

Various bits like this, please do a prep patch first moving things
around.

-- 
Jens Axboe

  reply	other threads:[~2025-07-23 17:23 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-23 17:04 [PATCH 0/2] io_uring r/w with metadata Vincent Fu
2025-07-23 17:04 ` [PATCH 1/2] engines/io_uring: support " Vincent Fu
2025-07-23 17:23   ` Jens Axboe [this message]
2025-07-23 17:37     ` Jens Axboe
2025-07-23 18:28       ` Vincent Fu
2025-07-23 19:23         ` Jens Axboe
2025-07-23 17:04 ` [PATCH 2/2] t/io_uring_pi: test script for io_uring PI Vincent Fu

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=15cb4581-7067-40fa-9a1b-8883c9993d2c@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=anuj1072538@gmail.com \
    --cc=anuj20.g@samsung.com \
    --cc=fio@vger.kernel.org \
    --cc=hch@infradead.org \
    --cc=joshi.k@samsung.com \
    --cc=vincent.fu@samsung.com \
    --cc=vincentfu@gmail.com \
    /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