Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

io_uring: Add 'write_mode' option for optional cmds #1766

Merged
merged 1 commit into from
Jun 3, 2024

Conversation

minwooim
Copy link
Contributor

@minwooim minwooim commented May 30, 2024

Add a new option 'write_mode' to support additional optional Write
command family such as Write Uncorrectable and Write Zeroes in NVMe.
Since we have io_uring_cmd ioengine where we can define the actual
opcode of the command, this option will be used to test NVMe device with
various combination of Write command types.

'write_mode' option can be given either 'write', 'uncor', 'zeroes' or
'verify'. 'write' is for normal Write command which is by default,
'uncor' is for Write Uncorrectable, 'zeroes' for Write Zeroes and 'verify'
for Verify command This should be used with DDIR_WRITE ddir.

This patch updates command's opcode in fio_ioring_init() to avoid
branches in the I/O hottest path giving opcode value to the
fio_nvme_uring_cmd_prep() as an argument.

@minwooim minwooim changed the title Add 'writetype' option for optional cmds [RFC] Add 'writetype' option for optional cmds May 30, 2024
@minwooim
Copy link
Contributor Author

@axboe @vincentkfu ,

Can we have a new DDIR only just for io_uring_cmd to support custom commands with an extra option like cmd ?
As io_uring_cmd ioengine has enabled flexible testing ways for storage devices by enabling ioengine can specify command descriptor details, it's so useful to test storage device with high and wide coverage. And I would really want to test storage device with various command types which have SLBA and NLB pattern other than typical I/O commands (READ/WRITE/TRIM).

If possible, I would like to introduce a cmd option with --rw=uring_cmd to support various spec-based commands rather than introducing a writetype which is might be too specific for WRITE commands only.

[global]
...
ioengine=io_uring_cmd
cmd_type=nvme
filename=/dev/ng0n1

[job0]
rw=uring_cmd
cmd=writeuncor

[job1]
rw=uring_cmd
cmd=writezeroes
...

@vincentkfu
Copy link
Collaborator

There is a similar option for the sg ioengine. Can you adopt that option for io_uring_cmd?

@minwooim minwooim force-pushed the io_uring_cmd/support-write-family branch from 2e9ae80 to 2f4c005 Compare May 31, 2024 09:43
@minwooim
Copy link
Contributor Author

There is a similar option for the sg ioengine. Can you adopt that option for io_uring_cmd?

That makes sense. I've updated parameter name to write_mode which is used in sg ioengine as sg_write_mode.

@minwooim minwooim changed the title [RFC] Add 'writetype' option for optional cmds Add 'writetype' option for optional cmds May 31, 2024
@minwooim minwooim changed the title Add 'writetype' option for optional cmds io_uring: Add 'write_mode' option for optional cmds May 31, 2024
engines/nvme.c Outdated
@@ -336,7 +336,6 @@ void fio_nvme_uring_cmd_trim_prep(struct nvme_uring_cmd *cmd, struct io_u *io_u,
uint8_t *buf_point;
int i;

cmd->opcode = nvme_cmd_dsm;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should not be removed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops, this is really bad. I will update it, thanks for catching this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated.

@vincentkfu
Copy link
Collaborator

The nomenclature here is not ideal because none of verify, write zeroes, and write uncorrectable will actually make use of the data buffer that fio prepares for write operations. By default fio will generate random data for the write buffer one time only. So this is probably not a big deal.

Add a new option 'write_mode' to support additional optional Write
command family such as Write Uncorrectable and Write Zeroes in NVMe.
Since we have io_uring_cmd ioengine where we can define the actual
opcode of the command, this option will be used to test NVMe device with
various combination of Write command types.

'write_mode' option can be given either 'write', 'uncor', 'zeroes' or
'verify'.  'write' is for normal Write command which is by default,
'uncor' is for Write Uncorrectable, 'zeroes' for Write Zeroes and 'verify'
for Verify command  This should be used with DDIR_WRITE ddir.

This patch updates command's opcode in fio_ioring_init() to avoid
branches in the I/O hottest path giving opcode value to the
fio_nvme_uring_cmd_prep() as an argument.

Signed-off-by: Minwoo Im <minwoo.im@samsung.com>
@minwooim
Copy link
Contributor Author

The nomenclature here is not ideal because none of verify, write zeroes, and write uncorrectable will actually make use of the data buffer that fio prepares for write operations. By default fio will generate random data for the write buffer one time only. So this is probably not a big deal.

Indeed, that's why I've been curious about whether the name of writetype is propero r not since it might be considered as WRITE family, but it might not due to non-data transfer. But, as you suggested in the previous review, I would prefer to have consistent name of write_mode along with sg ioengine for these commands. And yes, even fio prepares the actual DOUT buffer, I think it's not that a big deal not preventing data preparation for them.

@minwooim minwooim force-pushed the io_uring_cmd/support-write-family branch from 2f4c005 to 87a4903 Compare May 31, 2024 21:14
@axboe axboe merged commit 1757469 into axboe:master Jun 3, 2024
9 of 10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants