Re: [PATCH 6/9] libnvme: add support for per-path diagnostic counters

[Nilay Shroff <nilay@linux.ibm.com>]

On 3/24/26 2:48 PM, Daniel Wagner wrote:
> On Sat, Mar 21, 2026 at 08:58:05PM +0530, Nilay Shroff wrote:
>> Add support for retrieving per-path diagnostic counters such as
>> command_retry_count, command_error_count, and multipath_failover_count.
>> These counters improve visibility into NVMe native multipath behavior
>> and can be useful for tools such as nvme-top to display real-time
>> statistics.
>>
>> Unlike other sysfs attributes, these counters can change dynamically.
>> Annotate them with "!accessors:none" and provide custom implementations
>> to always retrieve the latest (non-cached) values.
> 
> If I got this right, this and the next patches depend on
> 
>     https://lore.kernel.org/all/20260220175024.292898-1-nilay@linux.ibm.com
> 
Yes you're correct, I am just waiting for Keith's response on that thread here:
https://lore.kernel.org/all/0832f4dd-0ab6-4e11-a404-fdb18ca699b2@linux.ibm.com/

> Should we wait with interfaces here until they are ready? As we
> currently still in the development phase of nvme-cli 3 and thus the API
> is not stable, we can touch it again. In the past we also added support
> for kernel feature which weren't there yet. I don't mind too much, just
> asking what would be best here.
> 

I’m fine either way regarding when to introduce these interfaces.
Even if we include the diagnostic counter patches now, it won’t break
anything. If the corresponding sysfs attributes are not present, the
library will simply return 0 for those counters.

There are essentially two options,

1. Include the diagnostic counter patches now:
    In this case, nvme-cli/nvme-top can start using the libnvme APIs immediately.
    If the kernel does not yet expose these attributes, the counters will appear
    as zero in the dashboard. Once the kernel support lands, the correct values
    will automatically be reflected without requiring further changes to libnvme
    or nvme-cli (unless the sysfs layout changes).

2. Defer the diagnostic counter patches:
    In this case, the counters would be omitted from the nvme-top dashboard for now.
    Once kernel support is available, we would need to update nvme-top (and libnvme)
    to add them.

Given these options, I would lean towards option (1), but I’m happy to go with
your preference.

> The whole series looks pretty good, just my nitpicks and the question
> on exposing 'cur'/'this'.

I will address nitpick comments in next patchset, and I have provided the rationale
about why we need to expose 'cur'/'this' in an earlier reply.

Thanks,
--Nilay