From: "Zawadzki, Tomasz" <tomasz.zawadzki@intel.com>
To: Keith Busch <kbusch@kernel.org>, Hannes Reinecke <hare@suse.de>
Cc: Jens Axboe <axboe@kernel.dk>, Christoph Hellwig <hch@lst.de>,
"Daniel Wagner" <dwagner@suse.de>,
"Brzezinka, Sebastian" <sebastian.brzezinka@intel.com>,
Sagi Grimberg <sagi@grimberg.me>,
"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>
Subject: RE: nvme-cli spdk plugin
Date: Thu, 18 Apr 2024 16:17:27 +0000 [thread overview]
Message-ID: <MN6PR11MB8103E3599A137C129353E577EE0E2@MN6PR11MB8103.namprd11.prod.outlook.com> (raw)
In-Reply-To: <ZiExvFvUPk4HOt3d@kbusch-mbp>
> 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.
next prev parent reply other threads:[~2024-04-18 16:17 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-17 8:33 nvme-cli spdk plugin Daniel Wagner
2024-04-17 9:44 ` Sagi Grimberg
2024-04-17 10:17 ` Brzezinka, Sebastian
2024-04-17 11:47 ` Daniel Wagner
2024-04-17 14:26 ` Christoph Hellwig
2024-04-17 14:31 ` Jens Axboe
2024-04-17 14:39 ` Jim
2024-04-17 14:57 ` Jens Axboe
2024-04-17 15:13 ` Jim
2024-04-18 6:25 ` Hannes Reinecke
2024-04-18 14:44 ` Keith Busch
2024-04-18 16:17 ` Zawadzki, Tomasz [this message]
2024-04-18 9:22 ` Sagi Grimberg
2024-04-18 12:04 ` Daniel Wagner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=MN6PR11MB8103E3599A137C129353E577EE0E2@MN6PR11MB8103.namprd11.prod.outlook.com \
--to=tomasz.zawadzki@intel.com \
--cc=axboe@kernel.dk \
--cc=dwagner@suse.de \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
--cc=sebastian.brzezinka@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).