nvme-cli spdk plugin

[Zawadzki, Tomasz]

> On Thu, Apr 18, 2024 at 08:25:45AM +0200, Hannes Reinecke wrote:
> > On 4/17/24 16:31, Jens Axboe wrote:
> > > On 4/17/24 8:26 AM, Christoph Hellwig wrote:
> > > > On Wed, Apr 17, 2024 at 10:33:17AM +0200, Daniel Wagner wrote:
> > > > > There is a PR [1] pending, adding a spdk plugin for nvme-cli.
> > > > > The problem this new plugin tries to solve is, that with the
> > > > > recent change to use sysfs only for discovering the nvme
> > > > > subystem, nvme-cli lost support for spdk.
> > > > >
> > > > > My question is, should we have a special plugin for 'list' and
> > > > > 'list-subsystem' or should we try to get this somehow integrated
> > > > > into the existing code? So that 'list' just works?
> > > >
> > > > І don't think nvme-cli should deal with anything that is not
> > > > driven by the kernel nvme driver.
> > >
> > > Exactly, why on earth would we care about spdk at all in the first
> > > place, nvme-cli or not.
> > >
> >
> > And that depends on the direction of development we want to take.
> > Do we want nvme-cli to become a 'general' nvme management tool, then
> > we should investigate in having an spdk plugin.
> > Or do we want to have nvme-cli as the cli for the linux nvme kernel
> > driver, then clearly we wouldn't need an spdk plugin.
> > That, I guess, is the real discussion.
> >
> > Personally I would vote for the first option. But I'm sure others have
> > other opinions.
> 
> I don't actively maintain this right now, so I think it's really up to Daniel. It
> made sense to me from a design stand point that this utility should have OS-
> agnostic abstractions. It's not a priority for me, but if people are willing to
> maintain non-linux kernel environments, and as long as that doesn't interfere
> with Linux kernel development or break existing kernel usage, then I don't see
> why not.

As mentioned in the other thread, SPDK has the ability to present itself as a CUSE device.
This allows for interaction with most of nvme-cli commands just by pointing to that device.
Issue is with list/list-subsystem that only relies on sysfs entries.

Changes made while splitting nvme-cli and libnvme a while ago made perfect sense,
along with removal of the fallback option of browsing /dev/nvme*. Reintroducing that
back was not something we've considered.

On the other hand adding a sysfs like representation for SPDK devices, would still require
some changes in libnvme. Those would be targeted specifically for that interface.
I think that using FUSE to represent that even got some positive attention since this thread,
yet its not something I've seen anyone plan to tackle. The concern here is that such approach
would still require modification of tools to make use of it, potentially defeating the purpose.

Thus trying to limit the scope of the changes to nvme-cli, we decided to propose the
SPDK plugin for those two commands. It is similar to other already existing plugins
that look up the path for list command. Besides has the benefit of being explicit,
so there is never confusion from the user point of view.

Please do let us know if you think there is a better way to introduce those types of changes.