[PATCHv2 1/7] nvme: export command retry count via sysfs

[Nilay Shroff]

On 2/7/26 6:58 PM, Sagi Grimberg wrote:
> 
> 
> On 05/02/2026 14:48, Nilay Shroff wrote:
>> When Advanced Command Retry Enable (ACRE) is configured, a controller
>> may interrupt command execution and return a completion status
>> indicating command interrupted with the DNR bit cleared. In this case,
>> the driver retries the command based on the Command Retry Delay (CRD)
>> value provided in the completion status.
>>
>> Currently, these command retries are handled entirely within the NVMe
>> driver and are not visible to userspace. As a result, there is no
>> observability into retry behavior, which can be a useful diagnostic
>> signal.
>>
>> Expose the command retries count through sysfs to provide visibility
>> into retry activity. This information can help identify controller-side
>> congestion under load and enables comparison across paths in multipath
>> setups (for example, detecting cases where one path experiences
>> significantly more retries than another under identical workloads).
>>
>> This exported metric is intended for diagnostics and monitoring tools
>> such as nvme-top, and does not change command retry behavior.
> 
> This is designed to show an accumulated value of how much retries were
> done on a namespace since boot? I'm wandering if this does not belong in
> debugfs?

Yes, that’s correct — the intent is to expose an accumulated count of command
retries for a namespace since boot.
While debugfs could be used for this type of diagnostic information, it would
not work well for the intended userspace consumption. The retry counter is
expected to be consumed by tools such as nvme-cli (and potentially nvme-top), 
so it needs to be available via sysfs. Relying on debugfs would make this
information unavailable on production systems where debugfs may not be enabled
or mounted. For that reason, exporting the metric through sysfs ensures it is
consistently accessible in production environments

Thanks,
--Nilay