[PATCH 3/3] tree: add attribute numa_nodes for NVMe path object

[Hannes Reinecke]

On 4/7/25 17:19, Daniel Wagner wrote:
> On Mon, Apr 07, 2025 at 07:49:41PM +0530, Nilay Shroff wrote:
>> Both approaches — either adding a no-cache flag or introducing dedicated
>> __no_cached APIs — would work. However, in my opinion, we should aim to
>> use a consistent method across both libnvme 1.x and 2.x versions.
> 
> There will be a lot of API changes for 2.x to address all the silly
> mistakes. That's way it will be a major version change.
> 
>> As we discussed during LSFMM, if we plan to implement an "nvme top" command,
>> we would need non-cached versions of these APIs even for nvme-cli.
> 
> Yes, that is why I brought up this discussion. For such a command we
> would need non cached versions. And I realize that we would need this
> feature also for other commands. So it's not just the queue depth which
> changes. Maybe we should just not try to add this feature to 1.x and
> rather start the 2.x project.
> 
>> So, using the same mechanism for both versions makes sense. Otherwise,
>> we’d also have to maintain different logic in nvme top depending on
>> the libnvme version, which adds unnecessary complexity.
> 
> I don't see a big problem here. Either use the 1.x or 2.x.

Why don't we make this option as non-cached by default?
In the end, there is limited usability in having it cached.

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