[PATCHv2 2/4] nvme: extend show-topology command to add support for multipath

[Hannes Reinecke]

On 9/1/25 18:36, Daniel Wagner wrote:
> Hi Nilay,
> 
> On Mon, Sep 01, 2025 at 02:51:09PM +0530, Nilay Shroff wrote:
>> Hi Daniel and Hannes,
>>
>> Just a gentle ping on this one...
>>
>> Do you agree with the reasoning I suggested for filtering
>> columns based on iopolicy? If we all have agreement then
>> I'd send out the next patchset with appropriate change.
> 
> I was waiting for Hannes input here as he was in discussion.
> 
Yeah, and he is fine with the latest changes. Probably should've been
a bit more vocal about it :-)

>>>> But really, I'm not sure if we should print out values from the various
>>>> I/O policies. For NUMA it probably makes sense, but for round-robin and
>>>> queue-depths the values are extremely volatile, so I wonder what benefit
>>>> for the user is here.
>>>>
>>>
>>> I think the qdepth output could still be useful. For example, if I/Os are
>>> queuing up on one path (perhaps because that path is slower), then the Qdepth
>>> value might help indicate something unusual or explain why one path is being
>>> chosen over another.
>>>
>>> That said, if we all agree that tools or scripts should ideally rely on JSON
>>> output for parsing, then the tabular output could be simplified further:
>>>
>>> - For numa iopolicy: print <Nodes> and exclude <Qdepth>.
>>> - For queue-depth iopolicy: print <Qdepth> and exclude <Nodes>.
>>> - For round-robin iopolicy: exclude both <Nodes> and <Qdepth>.
> 
> Looks reasonable to me.
> 
Yep, that's fine.

>>> Does this sound reasonable? Or do we still want to avoid printing
>>> <Qdepth> even for queue-depth iopolicy?
> 
> I am fine with printing the qdepth value as long it is documented what it
> means. IIRC there are other tools which just show a snapshot for some
> statistics.
> 
> BTW, some discussion on github regarding something like a
> 'monitor' feature: https://github.com/linux-nvme/nvme-cli/issues/2189
> Might be something to which could be considered here as well.
> Well, that might be tricky. The current 'tree' structure is build
once when the program starts up. Any changes to that structure after
that are not tracked, and there (currently) are no hooks for updating
it. So having a 'monitor' function will get tricky.

To do that we would either need a udev event receiver (using uevents
to update the tree structure) or looking into fanotify()/inotify().
Then the tree structure would always be up-to-date and things like
'monitor' will be possible.
Will be hell for the python bindings, mind :-(

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                  Kernel Storage Architect
hare at suse.de                                +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich