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

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

On 4/1/26 9:24 PM, Daniel Wagner wrote:
> On Tue, Mar 24, 2026 at 07:24:11PM +0530, Nilay Shroff wrote:
>> 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.
> 
> I’m not sure if I read the room right, but I sensed the patches might be
> blocked by the libmultipath project. If they’re just delayed for the
> usual reasons, I’m fine with option (1).
> 
I think that the proposed kernel changes shouldn't come in way for
libmultipath work, but let me ping Keith one more time... Oh I see
Keith is already in this mail list..

Keith,
I am not sure if you got a chance to review this:
https://lore.kernel.org/all/0832f4dd-0ab6-4e11-a404-fdb18ca699b2@linux.ibm.com/

But if possible, would you please help let us know your thought/suggestion about
the above thread?

> FWIW, the 3.0 release is still months away, so there’s no hurry. I still
> have a few TODO items and want to wait for feedback from LSFMM. I’ll
> likely start the -rc cycle after that. Realistically, 3.0 won't land
> until August.

Yes understood, sounds reasonable...

Thanks,
--Nilay