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 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