nvme-cli spdk plugin

Daniel Wagner dwagner at suse.de
Thu Apr 18 05:04:43 PDT 2024


On Thu, Apr 18, 2024 at 12:22:56PM +0300, Sagi Grimberg wrote:
> > > І 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.
>
> As long as it does not introduce a maintenance overhead I don't particularly
> care. My suggestion was simply to make nvme-cli operate on a path-prefix,
> which is a very minor change. One can even argue that its justified for a
> container
> bind mounts (although I've never seen someone bind mount to targets other
> than /sys and /dev ...)

FWIW, libnvme is already able to read from any prefix. This is feature
used in the unit tests. So getting the library to read also from a
'well-known' other path shouldn't be to hard to get working.

I don't mind to work on this or maintain this part.

> In any event, if the spdk folks can make their devices interop with
> nvme-cli, I personally
> am not strictly against it if it doesn't require a burden on nvme-cli.

Same here. I don't mind the plugin as such though would prefer if spdk
would also mimic the sysfs interface. My original question was if we
insist that spdk is providing a sysfs interface. If the general
consensus is, we don't really care about it, then I don't mind adding it
as plugin. A plugin is easily removed if things go south.



More information about the Linux-nvme mailing list