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