Commit 2903c655 authored by Tomasz Zawadzki's avatar Tomasz Zawadzki Committed by Jim Harris
Browse files

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: default avatarTomasz Zawadzki <tomasz.zawadzki@intel.com>
Change-Id: Icfe8baf7a7497ffa86fde9038001429c5a7bc4f6
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/4801


Tested-by: default avatarSPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: default avatarJim Harris <james.r.harris@intel.com>
Reviewed-by: default avatarAleksey Marchuk <alexeymar@mellanox.com>
Reviewed-by: default avatarPaul Luse <paul.e.luse@intel.com>
parent 78ad6728

doc/applications.md

+2 −5
Original line number Diff line number Diff line
@@ -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}

doc/bdev_module.md

+1 −1
Original line number Diff line number Diff line
@@ -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

doc/blobfs.md

+3 −3
Original line number Diff line number Diff line
@@ -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.

doc/iscsi.md

+1 −36
Original line number Diff line number Diff line
@@ -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

doc/spdkcli.md

+1 −1
Original line number Diff line number Diff line
@@ -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