| Message ID | 20220719135234.14039-1-ankit.kumar@samsung.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add basic test for nvme uring passthrough commands | expand |
On 7/19/2022 6:52 AM, Ankit Kumar wrote: > This patchset adds test/io_uring_passthrough.c to submit uring passthrough > commands to nvme-ns character device. The uring passthrough was introduced > with 5.19 io_uring. > > To send nvme uring passthrough commands we require helpers to fetch NVMe > char device (/dev/ngXnY) specific fields such as namespace id, lba size. There wouldn't be a way to run these tests using a more general configuration, would there? I spent way too much time trying to coax my systems into pretending it has this device. > > How to run: > ./test/io_uring_passthrough.t /dev/ng0n1 > > This covers basic write/read with verify for sqthread poll, > vectored / nonvectored and fixed IO buffers, which can be easily extended > in future. > > Ankit Kumar (5): > configure: check for nvme uring command support > io_uring.h: sync sqe entry with 5.20 io_uring > nvme: add nvme opcodes, structures and helper functions > test: add io_uring passthrough test > test/io_uring_passthrough: add test case for poll IO > > configure | 20 ++ > src/include/liburing/io_uring.h | 17 +- > test/Makefile | 1 + > test/io_uring_passthrough.c | 395 ++++++++++++++++++++++++++++++++ > test/nvme.h | 168 ++++++++++++++ > 5 files changed, 599 insertions(+), 2 deletions(-) > create mode 100644 test/io_uring_passthrough.c > create mode 100644 test/nvme.h >
On 8/11/22 6:43 PM, Casey Schaufler wrote: > On 7/19/2022 6:52 AM, Ankit Kumar wrote: >> This patchset adds test/io_uring_passthrough.c to submit uring passthrough >> commands to nvme-ns character device. The uring passthrough was introduced >> with 5.19 io_uring. >> >> To send nvme uring passthrough commands we require helpers to fetch NVMe >> char device (/dev/ngXnY) specific fields such as namespace id, lba size. > > There wouldn't be a way to run these tests using a more general > configuration, would there? I spent way too much time trying to > coax my systems into pretending it has this device. It's only plumbed up for nvme. Just use qemu with an nvme device? -drive id=drv1,if=none,file=nvme.img,aio=io_uring,cache.direct=on,discard=on \ -device nvme,drive=drv1,serial=blah2 Paul was pondering wiring up a no-op kind of thing for null, though.
On Thu, Aug 11, 2022 at 9:51 PM Jens Axboe <axboe@kernel.dk> wrote: > On 8/11/22 6:43 PM, Casey Schaufler wrote: > > On 7/19/2022 6:52 AM, Ankit Kumar wrote: > >> This patchset adds test/io_uring_passthrough.c to submit uring passthrough > >> commands to nvme-ns character device. The uring passthrough was introduced > >> with 5.19 io_uring. > >> > >> To send nvme uring passthrough commands we require helpers to fetch NVMe > >> char device (/dev/ngXnY) specific fields such as namespace id, lba size. > > > > There wouldn't be a way to run these tests using a more general > > configuration, would there? I spent way too much time trying to > > coax my systems into pretending it has this device. > > It's only plumbed up for nvme. Just use qemu with an nvme device? > > -drive id=drv1,if=none,file=nvme.img,aio=io_uring,cache.direct=on,discard=on \ > -device nvme,drive=drv1,serial=blah2 > > Paul was pondering wiring up a no-op kind of thing for null, though. Yep, I started working on that earlier this week, but I've gotten pulled back into the SCTP stuff to try and sort out something odd. Casey, what I have isn't tested, but I'll toss it into my next kernel build to make sure it at least doesn't crash on boot and if it looks good I'll send it to you off-list.
On 8/12/2022 8:33 AM, Paul Moore wrote: > On Thu, Aug 11, 2022 at 9:51 PM Jens Axboe <axboe@kernel.dk> wrote: >> On 8/11/22 6:43 PM, Casey Schaufler wrote: >>> On 7/19/2022 6:52 AM, Ankit Kumar wrote: >>>> This patchset adds test/io_uring_passthrough.c to submit uring passthrough >>>> commands to nvme-ns character device. The uring passthrough was introduced >>>> with 5.19 io_uring. >>>> >>>> To send nvme uring passthrough commands we require helpers to fetch NVMe >>>> char device (/dev/ngXnY) specific fields such as namespace id, lba size. >>> There wouldn't be a way to run these tests using a more general >>> configuration, would there? I spent way too much time trying to >>> coax my systems into pretending it has this device. >> It's only plumbed up for nvme. Just use qemu with an nvme device? >> >> -drive id=drv1,if=none,file=nvme.img,aio=io_uring,cache.direct=on,discard=on \ >> -device nvme,drive=drv1,serial=blah2 >> >> Paul was pondering wiring up a no-op kind of thing for null, though. > Yep, I started working on that earlier this week, but I've gotten > pulled back into the SCTP stuff to try and sort out something odd. > > Casey, what I have isn't tested, but I'll toss it into my next kernel > build to make sure it at least doesn't crash on boot and if it looks > good I'll send it to you off-list. Super. Playing with qemu configuration always seems to suck time and rarely gets me where I want to be.
On Fri, Aug 12, 2022 at 09:03:12AM -0700, Casey Schaufler wrote: >On 8/12/2022 8:33 AM, Paul Moore wrote: >> On Thu, Aug 11, 2022 at 9:51 PM Jens Axboe <axboe@kernel.dk> wrote: >>> On 8/11/22 6:43 PM, Casey Schaufler wrote: >>>> On 7/19/2022 6:52 AM, Ankit Kumar wrote: >>>>> This patchset adds test/io_uring_passthrough.c to submit uring passthrough >>>>> commands to nvme-ns character device. The uring passthrough was introduced >>>>> with 5.19 io_uring. >>>>> >>>>> To send nvme uring passthrough commands we require helpers to fetch NVMe >>>>> char device (/dev/ngXnY) specific fields such as namespace id, lba size. >>>> There wouldn't be a way to run these tests using a more general >>>> configuration, would there? I spent way too much time trying to >>>> coax my systems into pretending it has this device. >>> It's only plumbed up for nvme. Just use qemu with an nvme device? >>> >>> -drive id=drv1,if=none,file=nvme.img,aio=io_uring,cache.direct=on,discard=on \ >>> -device nvme,drive=drv1,serial=blah2 >>> >>> Paul was pondering wiring up a no-op kind of thing for null, though. >> Yep, I started working on that earlier this week, but I've gotten >> pulled back into the SCTP stuff to try and sort out something odd. >> >> Casey, what I have isn't tested, but I'll toss it into my next kernel >> build to make sure it at least doesn't crash on boot and if it looks >> good I'll send it to you off-list. > >Super. Playing with qemu configuration always seems to suck time >and rarely gets me where I want to be. FWIW, one more option (not easier than no-op/null though) is to emulate nvme over a regular-file using loopback-fabrics target. A coarse script is here - https://github.com/joshkan/loopback-nvme-uring/commit/96853963a196f2d307d4d8e60d1276a08b520307