nvmfd: A simple userspace daemon for the NVMe over Fabrics controller

[jhb]

Summary

This daemon can operate as a purely userspace controller exporting one
or more simulated RAM disks or local block devices as NVMe namespaces
to a remote host. In this case the daemon provides a discovery
controller with a single entry for an I/O controller.

nvmfd can also offload I/O controller queue pairs to the nvmft.ko
in-kernel Fabrics controller when -K is passed. In this mode, nvmfd
still accepts connections and performs initial transport-specific
negotitation in userland. The daemon still provides a userspace-only
discovery controller with a single entry for an I/O controller.
However, queue pairs for the I/O controller are handed off to the CTL
NVMF frontend.

Eventually ctld(8) should be refactored to to provide an abstraction
for the frontend protocol and the discovery and the kernel mode of
this daemon should be merged into ctld(8). At that point this daemon
can be moved to tools/tools/nvmf as a debugging tool (mostly as sample
code for a userspace controller using libnvmf).

Sponsored by: Chelsio Communications

[imp]

This seems good, but again, it's kinda huge and that makes careful review is hard.

usr.sbin/nvmfd/controller.c

26

Consider omitting the boilerplate, here and elsewhere in the reviews.

usr.sbin/nvmfd/devices.c

80

I'd make this a #define... it could be 4k too, or at least it might be nice.

286

what happens when malloc fails? core dump?

[jhb]

usr.sbin/nvmfd/devices.c

80

I guess this can use DEV_BSIZE as that is hardcoded as 512 in practice.

In theory this could be a configurable knob, but the userspace controller isn't really intended for serious production use, more for testing / debugging.

286

Yep. (Again, this is only relevant when running the userspace controller, not for the production use case).