Home

tnvme is a user space test application targeting the compliance verification of NVM Express (NVMe) compliant hardware. The NVMe home page is http://www.nvmexpress.org.

tnvme it not the complete compliance suite, rather it is the framework which empowers the building, and execution of compliance test cases. Further logic is necessary, in kernel space, to provide the low level support tnvme requires. The logic resident within the kernel is platform specific and the generic logic, non-platform specific, lives within tnvme. Currently the compliance suite targets Linux distributions only, however the design allows source code ports to other platforms by creating a corresponding kernel mode driver to implement the necessary IOCTL’s. The corresponding Linux kernel mode driver is dnvme which is resident within https://github.com/organizations/nvmecompliance as its own git repo.

tnvme is not a benchmark, throughput or performance measurement system, rather its goal is to verify hardware compliance against a written set of specifications. Functionality, not speed, was the main target of this application. It was seen that satisfying both speed and functionality could not be addressed simultaneously in all aspects of this design. Thus when a decision had to be made as to which one to choose, functionality always won.

Jump In

Compiling
Executing
Example Code

Introduction

Design Strategy
Test Strategy
Coding Standards

General Architectural Details

Groups
Tests
Resource Lifetime
Interrupts TBD...

Resources

In the most general sense, resources are those objects tnvme uses to setup and test a Device Under Test (DUT). Resources are commands from any command set, any type of queue, and memory (both contiguous and discontiguous with various alignment requirements). An alternative mechanism to view resources and the C++ classes which represent them is to generate the doxygen output against the source code.

1) cd tnvme
2) make doc
3) ./classHierarchy.sh

Queues
Commands
Memory

Singletons

Singletons are a design pattern in C++ to prohibit multiple instances of a particular class for each instance of an application. The singletons within this design are also global. Singletons serve to be the sole access into dnvme. This is enforced because the tnvme-dnvme interaction is forced to be single threaded. The following singletons serve as the only conduit into dnvme, and thus to a DUT to control a particular behavior. The singletons are organized to handle specific areas of logical operation.

gRsrcMngr
gCtrlrConfig
gRegisters