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

[Daniel Wagner]

On Tue, Apr 08, 2025 at 07:58:40AM +0200, Hannes Reinecke wrote:
> 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.

Sure, this is also fine. I suppose there will be some more conversion
from cached to non-cached necessary for the 'nvme top' feature.