Using Machine Learning for dynamic prediction of Controller Features by NVMe Monitor

The Non Volatile Memory Express standard is stimulating a new era of highly efficient and powerful mass
storage devices. But for all its strengths, it also sets new challenges for verification. This blog aims at
addressing the challenges in verifying the Set and Get features of NVMe Controller and suggests an algorithm
for a comprehensive environment built to verify these features with negligible user configuration to a NVMe
Monitor being operated in passive mode.
The stated algorithm works on the principle of “learning” from the response of first few transactions (Set and
Get Admin Commands) exchanged between NVMe Host and NVMe Controller.

As shown in Figure 1, NVMe Monitor unlike NVMe Controller does not hold default values nor the supported
capabilities for any of the features supported by NVMe Controller. Therefore, it becomes an arduous task of
not only capturing the feature values from NVMe transactions but also validating the response along with
feature values (against its predicted response and feature values).

A minor modification in specification defined data structure of NVMe Features can assist in implementing an
algorithm for verification of controller features using Set and Get Admin Command transactions.

Each controller feature implements its supported capability register (CAP) along with individual registers to
hold Current, Default and Saved values as shown in Figure 2. These data structures can be altered to
incorporate a “Valid” bit to represent validity of the contents of individual data structure.

NVMe Controller features include -

• Arbitration Feature
• Power Management Feature
• Temperature Threshold Feature
• Error Recovery Feature
• Number of Queues Feature
• Interrupt Coalescing Feature
• Interrupt Vector Configuration Feature
• Write Atomicity Normal Feature
• Asynchronous Event Configuration Feature, etc

An example of NVMe Power Management Feature with elaborated data structure is as shown in Figure 3.

Detailed flow charts explaining the usage of “Valid bit” upon reception of successful Get Features Admin
Completion Command at NVMe Monitor when Select field in Get Features command is supported / not
supported is as shown in Figure 4, 5, 6 and 7.

Flowchart convention

• Predictor Update
• Checks based on predictions
• Command Double Word 0 of Admin Completion Command
• Command Double Word 11 of Admin Submission Command
• Select bit in Get Features support is equal to Save bit in Set Features support which is equal to bit 4 of
• Optional NVM Command Support field in Identify Controller Data Structure

It can be observed from above flow charts that initial Get Features Completion is used to formulate prediction
for future Get Feature commands by setting the “Valid” bit to 1 upon extraction of corresponding data
structure(s). Moreover, some of these data structures can also be predicted from Set Feature command
causing the “Valid” bit to toggle to 1 even if a Get Feature was not encountered prior to a Set Feature
command.
Detailed flow charts explaining the usage of “Valid bit” upon reception of Set Features Admin Completion
Command at NVMe Monitor when Save field in Set Features command is supported / not supported is as
shown in Figure 8 and 9.

Where,
FNC = Feature Not Changeable
NA = Not Applicable
SC = Successful Completion
FINS = Feature Identifier Not Saveable

It can be concluded from Figure 8,9 and Table 1 that similar to Get Features, initial Set Features Completion
Status also aids in predicting the nature of capabilities supported by controller along with its response under all
possible scenarios when capabilities supported by any feature is known / not known to NVMe Monitor.

Advantages of adopting this algorithm -

• Easy Integration (Plug and Play)
• Minimum memory footprint
• Algorithm scalable to multiple features with multiple controllers
• Instead of conventional sequence based intentional checks, monitor checks are activated in each test
• case throughout the regression