[PATCH liburing] test/io_uring_passthrough: add test for vectored fixed-buffers

[PATCH liburing] test/io_uring_passthrough: add test for vectored fixed-buffers

[Anuj Gupta]

This patch adds support for vectored fixed buffer I/O using io_uring
nvme passthrough, enabling broader testing of this path. Since older
kernels may return -EINVAL for this combination (fixed + vectored), the
test now detects this failure at runtime via a vec_fixed_supported flag.
Subsequent iterations skip only the unsupported combinations while
continuing to test all other valid variants.

Signed-off-by: Anuj Gupta <anuj20.g@samsung.com>
---
 test/io_uring_passthrough.c | 23 ++++++++++++++++++++---
 1 file changed, 20 insertions(+), 3 deletions(-)

diff --git a/test/io_uring_passthrough.c b/test/io_uring_passthrough.c
index 66c97da..4a0ad73 100644
--- a/test/io_uring_passthrough.c
+++ b/test/io_uring_passthrough.c
@@ -20,6 +20,7 @@
 static void *meta_mem;
 static struct iovec *vecs;
 static int no_pt;
+static bool vec_fixed_supported = true;
 
 /*
  * Each offset in the file has the ((test_case / 2) * FILE_SIZE)
@@ -129,11 +130,15 @@ static int __test_io(const char *file, struct io_uring *ring, int tc, int read,
 				use_fd = 0;
 			if (fixed && (i & 1))
 				do_fixed = 0;
-			if (do_fixed) {
+			if (do_fixed && nonvec) {
 				io_uring_prep_read_fixed(sqe, use_fd, vecs[i].iov_base,
 								vecs[i].iov_len,
 								offset, i);
 				sqe->cmd_op = NVME_URING_CMD_IO;
+			} else if (do_fixed) {
+				io_uring_prep_readv_fixed(sqe, use_fd, &vecs[i],
+								1, offset, 0, i);
+				sqe->cmd_op = NVME_URING_CMD_IO_VEC;
 			} else if (nonvec) {
 				io_uring_prep_read(sqe, use_fd, vecs[i].iov_base,
 							vecs[i].iov_len, offset);
@@ -152,11 +157,15 @@ static int __test_io(const char *file, struct io_uring *ring, int tc, int read,
 				use_fd = 0;
 			if (fixed && (i & 1))
 				do_fixed = 0;
-			if (do_fixed) {
+			if (do_fixed && nonvec) {
 				io_uring_prep_write_fixed(sqe, use_fd, vecs[i].iov_base,
 								vecs[i].iov_len,
 								offset, i);
 				sqe->cmd_op = NVME_URING_CMD_IO;
+			} else if (do_fixed) {
+				io_uring_prep_writev_fixed(sqe, use_fd, &vecs[i],
+								1, offset, 0, i);
+				sqe->cmd_op = NVME_URING_CMD_IO_VEC;
 			} else if (nonvec) {
 				io_uring_prep_write(sqe, use_fd, vecs[i].iov_base,
 							vecs[i].iov_len, offset);
@@ -187,7 +196,7 @@ static int __test_io(const char *file, struct io_uring *ring, int tc, int read,
 		cmd->cdw11 = slba >> 32;
 		/* cdw12 represent number of lba's for read/write */
 		cmd->cdw12 = nlb;
-		if (do_fixed || nonvec) {
+		if (nonvec) {
 			cmd->addr = (__u64)(uintptr_t)vecs[i].iov_base;
 			cmd->data_len = vecs[i].iov_len;
 		} else {
@@ -218,6 +227,10 @@ static int __test_io(const char *file, struct io_uring *ring, int tc, int read,
 			goto err;
 		}
 		if (cqe->res != 0) {
+			if (cqe->res == -EINVAL && fixed && !nonvec) {
+				vec_fixed_supported = false;
+				goto cleanup_and_skip;
+			}
 			if (!no_pt) {
 				no_pt = 1;
 				goto skip;
@@ -236,6 +249,7 @@ static int __test_io(const char *file, struct io_uring *ring, int tc, int read,
 		}
 	}
 
+cleanup_and_skip:
 	if (fixed) {
 		ret = io_uring_unregister_buffers(ring);
 		if (ret) {
@@ -275,6 +289,9 @@ static int test_io(const char *file, int tc, int read, int sqthread,
 	if (hybrid)
 		ring_flags |= IORING_SETUP_IOPOLL | IORING_SETUP_HYBRID_IOPOLL;
 
+	if (fixed && (!vec_fixed_supported && !nonvec))
+		return 0;
+
 	ret = t_create_ring(64, &ring, ring_flags);
 	if (ret == T_SETUP_SKIP)
 		return 0;
-- 
2.25.1

Re: [PATCH liburing] test/io_uring_passthrough: add test for vectored fixed-buffers

[Pavel Begunkov]

On 5/21/25 09:19, Anuj Gupta wrote:
> This patch adds support for vectored fixed buffer I/O using io_uring
> nvme passthrough, enabling broader testing of this path. Since older
> kernels may return -EINVAL for this combination (fixed + vectored), the
> test now detects this failure at runtime via a vec_fixed_supported flag.
> Subsequent iterations skip only the unsupported combinations while
> continuing to test all other valid variants.

LGTM, it's great to have the test, thanks Anuj. FWIW, that's the
same way I tested the kernel patch.

Somewhat unrelated questions, is there some particular reason why all
vectored versions are limited to 1 entry iovec? And why do we even care
calling io_uring_prep_read/write*() helpers when non of the rw related
fields set are used by passthrough? i.e. iovec passed in the second half
of the sqe.

-- 
Pavel Begunkov

Re: [PATCH liburing] test/io_uring_passthrough: add test for vectored fixed-buffers

[Anuj gupta]

> LGTM, it's great to have the test, thanks Anuj. FWIW, that's the
> same way I tested the kernel patch.
>
> Somewhat unrelated questions, is there some particular reason why all
> vectored versions are limited to 1 entry iovec? And why do we even care
> calling io_uring_prep_read/write*() helpers when non of the rw related
> fields set are used by passthrough? i.e. iovec passed in the second half
> of the sqe.

Thanks, Pavel!

Regarding the vectored I/O being limited to 1 iovec — yeah, I kept it
simple initially because the plumbing was easier that way. It’s the same
in test/read-write.c, where vectored calls also use just one iovec. But
I agree, for better coverage, it makes sense to test with multiple
iovecs. I’ll prepare and post a follow-up patch that adds that.

About the use of io_uring_prep_read/write*() helpers — you're right,
they don’t really add much here since the passthrough command handles
the fields directly. I’ll work on a cleanup patch to remove those and
simplify the submission code.

>
> --
> Pavel Begunkov
>

Re: [PATCH liburing] test/io_uring_passthrough: add test for vectored fixed-buffers

[Jens Axboe]

On 5/21/25 4:35 AM, Anuj gupta wrote:
>> LGTM, it's great to have the test, thanks Anuj. FWIW, that's the
>> same way I tested the kernel patch.
>>
>> Somewhat unrelated questions, is there some particular reason why all
>> vectored versions are limited to 1 entry iovec? And why do we even care
>> calling io_uring_prep_read/write*() helpers when non of the rw related
>> fields set are used by passthrough? i.e. iovec passed in the second half
>> of the sqe.
> 
> Thanks, Pavel!
> 
> Regarding the vectored I/O being limited to 1 iovec ? yeah, I kept it
> simple initially because the plumbing was easier that way. It?s the same
> in test/read-write.c, where vectored calls also use just one iovec. But
> I agree, for better coverage, it makes sense to test with multiple
> iovecs. I?ll prepare and post a follow-up patch that adds that.

We really should ensure it exercises at least the three common types
for iovec imports:

1) Single segment
2) Multi segment, but below dynamic alloc range
3) Multi segment, above (or equal) to dynamic alloc range

These days 2+3 are the same thing, so makes it a bit easier, as we
just embed a single vec.

Bonus points if you want to send followup patches for both the
passthrough and read-write case using eg 4 segments or something
like that.

-- 
Jens Axboe

Re: [PATCH liburing] test/io_uring_passthrough: add test for vectored fixed-buffers

[Jens Axboe]

On Wed, 21 May 2025 13:49:49 +0530, Anuj Gupta wrote:
> This patch adds support for vectored fixed buffer I/O using io_uring
> nvme passthrough, enabling broader testing of this path. Since older
> kernels may return -EINVAL for this combination (fixed + vectored), the
> test now detects this failure at runtime via a vec_fixed_supported flag.
> Subsequent iterations skip only the unsupported combinations while
> continuing to test all other valid variants.
> 
> [...]

Applied, thanks!

[1/1] test/io_uring_passthrough: add test for vectored fixed-buffers
      commit: 78a86bc03ad3cd7ee0f509e317b225eb5994695d

Best regards,
-- 
Jens Axboe

Re: [PATCH liburing] test/io_uring_passthrough: add test for vectored fixed-buffers

[Pavel Begunkov]

On 5/21/25 11:35, Anuj gupta wrote:
>> LGTM, it's great to have the test, thanks Anuj. FWIW, that's the
>> same way I tested the kernel patch.
>>
>> Somewhat unrelated questions, is there some particular reason why all
>> vectored versions are limited to 1 entry iovec? And why do we even care
>> calling io_uring_prep_read/write*() helpers when non of the rw related
>> fields set are used by passthrough? i.e. iovec passed in the second half
>> of the sqe.
> 
> Thanks, Pavel!
> 
> Regarding the vectored I/O being limited to 1 iovec — yeah, I kept it
> simple initially because the plumbing was easier that way. It’s the same
> in test/read-write.c, where vectored calls also use just one iovec. But
> I agree, for better coverage, it makes sense to test with multiple
> iovecs. I’ll prepare and post a follow-up patch that adds that.

Got it, it's overlooked that rw doesn't pass longer iovecs. It'd be
great to unify the main loops of read-write.c, iopoll.c and nvme
passthrough tests. All of them do the same thing just initialising
sqes in different ways.

> About the use of io_uring_prep_read/write*() helpers — you're right,
> they don’t really add much here since the passthrough command handles
> the fields directly. I’ll work on a cleanup patch to remove those and
> simplify the submission code.

I don't care about the test itself much, but it means there
are lots of unused fields for the nvme commands that are not
checked by the kernel and hence can't be reused in the future.
That's not great

-- 
Pavel Begunkov

Re: [PATCH liburing] test/io_uring_passthrough: add test for vectored fixed-buffers

[Jens Axboe]

On 5/21/25 8:05 AM, Pavel Begunkov wrote:
>> About the use of io_uring_prep_read/write*() helpers ? you're right,
>> they don?t really add much here since the passthrough command handles
>> the fields directly. I?ll work on a cleanup patch to remove those and
>> simplify the submission code.
> 
> I don't care about the test itself much, but it means there
> are lots of unused fields for the nvme commands that are not
> checked by the kernel and hence can't be reused in the future.
> That's not great

It's still a pretty recent addition, no reason we can't add the checks
and get them back to stable as well. At least that would open the door
for more easy future expansion.

-- 
Jens Axboe

Re: [PATCH liburing] test/io_uring_passthrough: add test for vectored fixed-buffers

[Anuj gupta]

> > Regarding the vectored I/O being limited to 1 iovec ? yeah, I kept it
> > simple initially because the plumbing was easier that way. It?s the same
> > in test/read-write.c, where vectored calls also use just one iovec. But
> > I agree, for better coverage, it makes sense to test with multiple
> > iovecs. I?ll prepare and post a follow-up patch that adds that.
>
> We really should ensure it exercises at least the three common types
> for iovec imports:
>
> 1) Single segment
> 2) Multi segment, but below dynamic alloc range
> 3) Multi segment, above (or equal) to dynamic alloc range
>
> These days 2+3 are the same thing, so makes it a bit easier, as we
> just embed a single vec.
>
> Bonus points if you want to send followup patches for both the
> passthrough and read-write case using eg 4 segments or something
> like that.
>

Thanks, Jens. Makes sense.
I’ll follow up with patches to cover all those vectored I/O cases.

> --
> Jens Axboe

Re: [PATCH liburing] test/io_uring_passthrough: add test for vectored fixed-buffers

[Jens Axboe]

On 5/21/25 8:20 AM, Anuj gupta wrote:
>>> Regarding the vectored I/O being limited to 1 iovec ? yeah, I kept it
>>> simple initially because the plumbing was easier that way. It?s the same
>>> in test/read-write.c, where vectored calls also use just one iovec. But
>>> I agree, for better coverage, it makes sense to test with multiple
>>> iovecs. I?ll prepare and post a follow-up patch that adds that.
>>
>> We really should ensure it exercises at least the three common types
>> for iovec imports:
>>
>> 1) Single segment
>> 2) Multi segment, but below dynamic alloc range
>> 3) Multi segment, above (or equal) to dynamic alloc range
>>
>> These days 2+3 are the same thing, so makes it a bit easier, as we
>> just embed a single vec.
>>
>> Bonus points if you want to send followup patches for both the
>> passthrough and read-write case using eg 4 segments or something
>> like that.
>>
> 
> Thanks, Jens. Makes sense.
> I’ll follow up with patches to cover all those vectored I/O cases.

Great, thanks!

-- 
Jens Axboe

Re: [PATCH liburing] test/io_uring_passthrough: add test for vectored fixed-buffers

[Pavel Begunkov]

On 5/21/25 15:14, Jens Axboe wrote:
> On 5/21/25 8:05 AM, Pavel Begunkov wrote:
>>> About the use of io_uring_prep_read/write*() helpers ? you're right,
>>> they don?t really add much here since the passthrough command handles
>>> the fields directly. I?ll work on a cleanup patch to remove those and
>>> simplify the submission code.
>>
>> I don't care about the test itself much, but it means there
>> are lots of unused fields for the nvme commands that are not
>> checked by the kernel and hence can't be reused in the future.
>> That's not great
> 
> It's still a pretty recent addition, no reason we can't add the checks
> and get them back to stable as well. At least that would open the door
> for more easy future expansion.

nvme passthrough? It has been around for a while

commit 456cba386e94f22fa1b1426303fdcac9e66b1417
Author: Kanchan Joshi <joshi.k@samsung.com>
Date:   Wed May 11 11:17:48 2022 +0530

     nvme: wire-up uring-cmd support for io-passthru on char-device.


and if people followed the test for initialising sqes, it'll start
failing for them.

-- 
Pavel Begunkov

Re: [PATCH liburing] test/io_uring_passthrough: add test for vectored fixed-buffers

[Jens Axboe]

On 5/21/25 8:46 AM, Pavel Begunkov wrote:
> On 5/21/25 15:14, Jens Axboe wrote:
>> On 5/21/25 8:05 AM, Pavel Begunkov wrote:
>>>> About the use of io_uring_prep_read/write*() helpers ? you're right,
>>>> they don?t really add much here since the passthrough command handles
>>>> the fields directly. I?ll work on a cleanup patch to remove those and
>>>> simplify the submission code.
>>>
>>> I don't care about the test itself much, but it means there
>>> are lots of unused fields for the nvme commands that are not
>>> checked by the kernel and hence can't be reused in the future.
>>> That's not great
>>
>> It's still a pretty recent addition, no reason we can't add the checks
>> and get them back to stable as well. At least that would open the door
>> for more easy future expansion.
> 
> nvme passthrough? It has been around for a while
> 
> commit 456cba386e94f22fa1b1426303fdcac9e66b1417
> Author: Kanchan Joshi <joshi.k@samsung.com>
> Date:   Wed May 11 11:17:48 2022 +0530
> 
>     nvme: wire-up uring-cmd support for io-passthru on char-device.
> 
> 
> and if people followed the test for initialising sqes, it'll start
> failing for them.

Huh yes, that's older than I thought, we'd need to got back to 6.1
stable for that. Which isn't a huge deal, but also seems like the
risk would be too high at that point. Unfortunately lots of folks use
odd ball distro kernels that don't diligently pull stable fixes.

-- 
Jens Axboe