NVMe library
The NVMe library has been changed to create its own request memory pool rather than
requiring the user to initialize the global request_mempool
variable. Apps can be
updated by simply removing the initialization of request_mempool
. Since the NVMe
library user no longer needs to know the size of the internal NVMe request
structure to create the pool, the spdk_nvme_request_size()
function was also removed.
The spdk_nvme_ns_cmd_deallocate()
function was renamed and extended to become
spdk_nvme_ns_cmd_dataset_management()
, which allows access to all of the NVMe
Dataset Management command's parameters. Existing callers can be updated to use
spdk_nvme_ns_cmd_dataset_management()
with SPDK_NVME_DSM_ATTR_DEALLOCATE
as the
type
parameter.
The NVMe library SGL callback prototype has been changed to return virtual addresses
rather than physical addresses. Callers of spdk_nvme_ns_cmd_readv()
and
spdk_nvme_ns_cmd_writev()
must update their next_sge_fn
callbacks to match.
The NVMe library now supports NVMe over Fabrics devices in addition to the existing
support for local PCIe-attached NVMe devices. For an example of how to enable
NVMe over Fabrics support in an application, see examples/nvme/identify
and
examples/nvme/perf
.
Hot insert/remove support for NVMe devices has been added. To enable NVMe hotplug
support, an application should call the spdk_nvme_probe()
function on a regular
basis to probe for new devices (reported via the existing probe_cb
callback) and
removed devices (reported via a new remove_cb
callback). Hotplug is currently
only supported on Linux with the uio_pci_generic
driver, and newly-added NVMe
devices must be bound to uio_pci_generic
by an external script or tool.
Multiple processes may now coordinate and use a single NVMe device simultaneously
using DPDK Multi-process Support.
NVMe over Fabrics target (nvmf_tgt
)
The nvmf_tgt
configuration file format has been updated significantly to enable
new features. See the example configuration file etc/spdk/nvmf.conf.in
for
more details on the new and changed options.
The NVMe over Fabrics target now supports virtual mode subsystems, which allow the
user to export devices from the SPDK block device abstraction layer as NVMe over
Fabrics subsystems. Direct mode (raw NVMe device access) is also still supported,
and a single nvmf_tgt
may export both types of subsystems simultaneously.
Block device abstraction layer (bdev)
The bdev layer now supports scatter/gather read and write I/O APIs, and the NVMe
blockdev driver has been updated to support scatter/gather. Apps can use the
new scatter/gather support via the spdk_bdev_readv()
and spdk_bdev_writev()
functions.
The bdev status returned from each I/O has been extended to pass through NVMe
or SCSI status codes directly in cases where the underlying device can provide
a more specific status code.
A Ceph RBD (RADOS Block Device) blockdev driver has been added. This allows the
iscsi_tgt
and nvmf_tgt
apps to export Ceph RBD volumes as iSCSI LUNs or
NVMe namespaces.
General changes
libpciaccess
has been removed as a dependency and DPDK PCI enumeration is
used instead. Prior to DPDK 16.07 enumeration by class code was not supported,
so for earlier DPDK versions, only Intel SSD DC P3x00 devices will be discovered
by the NVMe library.
The env
environment abstraction library has been introduced, and a default
DPDK-based implementation is provided as part of SPDK. The goal of the env
layer is to enable use of alternate user-mode memory allocation and PCI access
libraries. See PORTING.md
for more details.
The build process has been modified to produce all of the library files in the
build/lib
directory. This is intended to simplify the use of SPDK from external
projects, which can now link to SPDK libraries by adding the build/lib
directory
to the library path via -L
and linking the SPDK libraries by name (for example,
-lspdk_nvme -lspdk_log -lspdk_util
).
nvmf_tgt
and iscsi_tgt
now have a JSON-RPC interface, which allows the user
to query and modify the configuration at runtime. The RPC service is disabled by
default, since it currently does not provide any authentication or security
mechanisms; it should only be enabled on systems with controlled user access
behind a firewall. An example RPC client implemented in Python is provided in
scripts/rpc.py
.
Documentation
Full documentation for this release is available at http://www.spdk.io/spdk/v16.12/doc/.