From 2903c6553346cbf46bc6b3e1c0dc9e26a12d8380 Mon Sep 17 00:00:00 2001 From: Tomasz Zawadzki Date: Wed, 21 Oct 2020 06:10:22 -0400 Subject: [PATCH] doc: remove mentions of legacy config Support for legacy configuration has been removed from SPDK at this point. This patch focuses on adjustement in documentation and examples. Signed-off-by: Tomasz Zawadzki Change-Id: Icfe8baf7a7497ffa86fde9038001429c5a7bc4f6 Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/4801 Tested-by: SPDK CI Jenkins Reviewed-by: Jim Harris Reviewed-by: Aleksey Marchuk Reviewed-by: Paul Luse --- doc/applications.md | 7 ++--- doc/bdev_module.md | 2 +- doc/blobfs.md | 6 ++-- doc/iscsi.md | 37 +------------------------ doc/spdkcli.md | 2 +- doc/vmd.md | 6 ---- examples/bdev/fio_plugin/README.md | 3 -- examples/bdev/fio_plugin/full_bench.fio | 2 +- 8 files changed, 9 insertions(+), 56 deletions(-) diff --git a/doc/applications.md b/doc/applications.md index 20177ca44..9afbba27c 100644 --- a/doc/applications.md +++ b/doc/applications.md @@ -49,11 +49,8 @@ Param | Long Param | Type | Default | Descript ### Configuration file {#cmd_arg_config_file} -Historically, the SPDK applications were configured using a configuration file. -This is still supported, but is considered deprecated in favor of JSON RPC -configuration. See @ref jsonrpc for details. - -Note that `--config` and `--wait-for-rpc` cannot be used at the same time. +SPDK applications are configured using a JSON RPC configuration file. +See @ref jsonrpc for details. ### Limit coredump {#cmd_arg_limit_coredump} diff --git a/doc/bdev_module.md b/doc/bdev_module.md index 191a1cf53..68e1ba03e 100644 --- a/doc/bdev_module.md +++ b/doc/bdev_module.md @@ -153,7 +153,7 @@ the I/O to other block devices. The canonical example would be a bdev module that implements RAID. Virtual bdevs are created in the same way as regular bdevs, but take one additional step. The module can look up the underlying bdevs it wishes to route I/O to using spdk_bdev_get_by_name(), where the string -name is provided by the user in a configuration file or via an RPC. The module +name is provided by the user via an RPC. The module then may proceed is normal by opening the bdev to obtain a descriptor, and creating I/O channels for the bdev (probably in response to the `get_io_channel` callback). The final step is to have the module use its open diff --git a/doc/blobfs.md b/doc/blobfs.md index 221abed4d..b1fd40ebb 100644 --- a/doc/blobfs.md +++ b/doc/blobfs.md @@ -37,7 +37,7 @@ export USE_RTTI=1 && make db_bench DEBUG_LEVEL=0 SPDK_DIR=path/to/spdk Create an NVMe section in the configuration file using SPDK's `gen_nvme.sh` script. ~~~{.sh} -scripts/gen_nvme.sh > /usr/local/etc/spdk/rocksdb.conf +scripts/gen_nvme.sh > /usr/local/etc/spdk/rocksdb.json ~~~ Verify the configuration file has specified the correct NVMe SSD. @@ -54,7 +54,7 @@ HUGEMEM=5120 scripts/setup.sh Create an empty SPDK blobfs for testing. ~~~{.sh} -test/blobfs/mkfs/mkfs /usr/local/etc/spdk/rocksdb.conf Nvme0n1 +test/blobfs/mkfs/mkfs /usr/local/etc/spdk/rocksdb.json Nvme0n1 ~~~ At this point, RocksDB is ready for testing with SPDK. Three `db_bench` parameters are used to configure SPDK: @@ -74,7 +74,7 @@ BlobFS provides a FUSE plug-in to mount an SPDK BlobFS as a kernel filesystem fo The FUSE plug-in requires fuse3 and will be built automatically when fuse3 is detected on the system. ~~~{.sh} -test/blobfs/fuse/fuse /usr/local/etc/spdk/rocksdb.conf Nvme0n1 /mnt/fuse +test/blobfs/fuse/fuse /usr/local/etc/spdk/rocksdb.json Nvme0n1 /mnt/fuse ~~~ Note that the FUSE plug-in has some limitations - see the list below. diff --git a/doc/iscsi.md b/doc/iscsi.md index 7ba30cd9d..cf6304f69 100644 --- a/doc/iscsi.md +++ b/doc/iscsi.md @@ -23,24 +23,6 @@ document. ![iSCSI structure](iscsi.svg) -## Configuring iSCSI Target via config file {#iscsi_config} - -A `iscsi_tgt` specific configuration file is used to configure the iSCSI target. A fully documented -example configuration file is located at `etc/spdk/iscsi.conf.in`. - -The configuration file is used to configure the SPDK iSCSI target. This file defines the following: -TCP ports to use as iSCSI portals; general iSCSI parameters; initiator names and addresses to allow -access to iSCSI target nodes; number and types of storage backends to export over iSCSI LUNs; iSCSI -target node mappings between portal groups, initiator groups, and LUNs. - -You should make a copy of the example configuration file, modify it to suit your environment, and -then run the iscsi_tgt application and pass it the configuration file using the -c option. Right now, -the target requires elevated privileges (root) to run. - -~~~ -build/bin/iscsi_tgt -c /path/to/iscsi.conf -~~~ - ### Assigning CPU Cores to the iSCSI Target {#iscsi_config_lcore} SPDK uses the [DPDK Environment Abstraction Layer](http://dpdk.org/doc/guides/prog_guide/env_abstraction_layer.html) @@ -57,26 +39,9 @@ command line option is used to configure the SPDK iSCSI target: This is a hexadecimal bit mask of the CPU cores where the iSCSI target will start polling threads. In this example, CPU cores 24, 25, 26 and 27 would be used. -### Configuring a LUN in the iSCSI Target {#iscsi_lun} - -Each LUN in an iSCSI target node is associated with an SPDK block device. See @ref bdev -for details on configuring SPDK block devices. The block device to LUN mappings are specified in the -configuration file as: - -~~~~ -[TargetNodeX] - LUN0 Malloc0 - LUN1 Nvme0n1 -~~~~ - -This exports a malloc'd target. The disk is a RAM disk that is a chunk of memory allocated by iscsi in -user space. It will use offload engine to do the copy job instead of memcpy if the system has enough DMA -channels. - ## Configuring iSCSI Target via RPC method {#iscsi_rpc} -In addition to the configuration file, the iSCSI target may also be configured via JSON-RPC calls. See -@ref jsonrpc for details. +The iSCSI target is configured via JSON-RPC calls. See @ref jsonrpc for details. ### Portal groups diff --git a/doc/spdkcli.md b/doc/spdkcli.md index 74994fc4a..8d3791fc2 100644 --- a/doc/spdkcli.md +++ b/doc/spdkcli.md @@ -18,7 +18,7 @@ Package dependencies at the moment include: ~~~{.sh} ./scripts/setup.sh -./build/bin/vhost -c vhost.conf +./build/bin/vhost -c vhost.json ~~~ ### Run SPDK CLI diff --git a/doc/vmd.md b/doc/vmd.md index a9572c5b8..6794ecc17 100644 --- a/doc/vmd.md +++ b/doc/vmd.md @@ -79,12 +79,6 @@ $ ./scripts/rpc.py bdev_nvme_attach_controller -b NVMe1 -t PCIe -a 5d0505:01:00. When application framework is used, VMD section needs to be added to the configuration file: -Text config: -``` -[VMD] - Enable True -``` - JSON config: ``` { diff --git a/examples/bdev/fio_plugin/README.md b/examples/bdev/fio_plugin/README.md index ad62247f5..38e7dbe06 100644 --- a/examples/bdev/fio_plugin/README.md +++ b/examples/bdev/fio_plugin/README.md @@ -51,9 +51,6 @@ The fio configuration file must contain one new parameter: spdk_json_conf=./examples/bdev/fio_plugin/bdev.json -This must point at an SPDK configuration file. There are a number of example configuration -files in the SPDK repository under etc/spdk. - You can specify which block device to run against by setting the filename parameter to the block device name: diff --git a/examples/bdev/fio_plugin/full_bench.fio b/examples/bdev/fio_plugin/full_bench.fio index f76da18db..b8faf679f 100644 --- a/examples/bdev/fio_plugin/full_bench.fio +++ b/examples/bdev/fio_plugin/full_bench.fio @@ -1,6 +1,6 @@ [global] ioengine=spdk_bdev -spdk_conf=./examples/bdev/fio_plugin/bdev.conf.in +spdk_conf=./examples/bdev/fio_plugin/bdev.json thread=1 group_reporting=1 direct=1