Re: [LTP] [PATCH v3] testcases/kernel/device-drivers/nvme: Add NVMe device discovery test

[Shin'ichiro Kawasaki via ltp <ltp@lists.linux.it>]

Hello Priyama,

From blktests maintainer side, let me share my views on your proposal.

Blktests started as the community effort among the kernel storage sub-system
developers. It was discussed at LSF/MM 2017, and started as the place to stock
test scripts for the kernel stroage sub-system. In my understanding, the
developers expect blktests is the test set to run before posting patches for the
storage subsystem. In the same manner, I expect and hope that nvme driver
patches tested with the nvme test group in blktests, to reduce the load of
reviewers and maintainers.

When LTP supports the nvme tests as you propose, what will be your expectation
for nvme driver patch submitters? Do you expect they run both blktests nvme test
group and LTP nvme group? If so, I suggest to add linux-nvme mailing list to
this discussion thread to ask their opinions.

Also, please find my inline comment below.

On May 25, 2026 / 11:00, priyama2 wrote:
> Hi Sebastian,
> 
> Thank you for raising this important question. After reviewing blktests'
> coverage, I see the concern about duplication.
> 
> *Proposed LTP NVMe Test Suite - System Integration Focus:*
> 
> Rather than duplicating blktests' comprehensive NVMe protocol testing, I
> propose LTP focus on system-level integration and kernel API validation.

The primary role of the blktests nvme test group is to cover the nvme driver
codes in the kernel source tree. It is not intended to test NVMe protocol or
NVMe devices. Blktests can be used for NVMe protocol/device testing as just a
side effect.

  It is often discussed to extend blktests to cover NVMe device compatibility
  test with Linux nvme driver, but it is still an idea at this moment.

I guess you misunderstood this point, so the list below still has duplications
with the blktests coverage. It will make it difficult to tell which test
framework (blktests or LTP) to add new nvme driver tests.

  Said that, the list below includes testing aspects that is not yet covered.
  I agree that those ideas are great.


> Here's an overview of the planned test suite:
> 
> *1. nvme01 - Device Discovery & System Integration (Current Patch)*
> 
>  * Basic device enumeration through /sys and /dev interfaces
>  * Driver binding verification
>  * *LTP-specific angle*: Validates kernel's sysfs/devfs integration,
>    not NVMe protocol
> 
> *2. nvme02 - File System Operations (Planned)*
> 
>  * Standard POSIX I/O operations (open, read, write, close, fsync)
>  * O_DIRECT, O_SYNC flag behavior
>  * mmap() operations on NVMe-backed files
>  * File locking (flock, fcntl) with NVMe storage
>  * *Differentiation*: Tests syscall interface, not NVMe commands
> 
> *3. nvme03 - Process & Thread Safety (Planned)*
> 
>  * Concurrent access from multiple processes
>  * fork() with open NVMe file descriptors
>  * Thread-safe I/O operations
>  * Signal handling during NVMe I/O
>  * *Differentiation*: Multi-process integration, not device-level testing
> 
> *4. nvme04 - Resource Management & Limits (Planned)*
> 
>  * Cgroup I/O throttling with NVMe devices
>  * ulimit enforcement (RLIMIT_FSIZE, RLIMIT_NOFILE)
>  * Disk quota behavior on NVMe filesystems
>  * Memory pressure scenarios
>  * *Differentiation*: Kernel resource management integration
> 
> *Key Differentiators from blktests:*
> 
> Aspect 	blktests 	LTP (Proposed)
> *Focus* 	NVMe protocol & features 	System call & kernel API
> *Scope* 	Block layer specifics 	Multi-subsystem integration
> *Interface* 	NVMe commands, ioctl 	POSIX syscalls (read/write/open)
> *Duration* 	Comprehensive (longer) 	Smoke tests (<5 min total)
> *Use Case* 	NVMe validation 	System regression detection
> 
> *Concrete Examples of LTP-Specific Value:*
> 
> 1. *System Integration*: Does|fsync()|properly flush NVMe write cache
>    through the kernel's VFS layer?
> 2. *Process Safety*: Can a child process inherit and use parent's NVMe
>    file descriptor after|fork()|?
> 3. *Resource Limits*: Does cgroup I/O throttling correctly limit NVMe
>    bandwidth?
> 4. *Platform Coverage*: Does NVMe work in PowerPC LPAR, s390x LPAR, ARM
>    virtualization?
> 5. *Container Integration*: Are NVMe devices properly accessible in
>    containerized environments?
> 
> *Positioning:*
> 
>  * *blktests*: "Does NVMe hardware/protocol work correctly?"
>  * *LTP*: "Does the kernel's NVMe integration work with the rest of the
>    system?"
> 
> *Current Status & Next Steps:*
> 
> The current nvme01 patch is admittedly basic. I'm happy to:
> 
> 1. *Withdraw*if LTP prefers no NVMe coverage
> 2. *Refocus*nvme01 on system integration (e.g., test sysfs attribute
>    access patterns)
> 3. *Proceed*with the differentiated test suite outlined above
> 4. *Collaborate*with blktests maintainers to ensure no overlap
> 
> Please let know which direction would the LTP community prefer?
> 
> Best regards, priyama2

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp