Most of the devices need to send RPCs during initialization (e.g. create
a transport), so we need to take care that they're initialized only
after we are certain that the SPDK process is listening.
The mechanisim is similar to the `waitforlisten` function used in our
test scripts - it sends a series of `rpc_get_methods` calls and times
out after a period of time if no response is received. For now, the
timeout is hardcoded to 60s.
Signed-off-by: Konrad Sztyber <konrad.sztyber@intel.com>
Change-Id: Iddadc04ad4c486d2894bc40e1a899a9d204400fc
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/11802
Community-CI: Broadcom CI <spdk-ci.pdl@broadcom.com>
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Reviewed-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com>
If the app is killed with either one of these signals, it'll shutdown
gracefully and exit with zero.
Signed-off-by: Konrad Sztyber <konrad.sztyber@intel.com>
Change-Id: I630f9e34c3ccb382c8e1b53d0f589f3ec4d1483b
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/11727
Community-CI: Broadcom CI <spdk-ci.pdl@broadcom.com>
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Reviewed-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com>
This allows a user to specify the types of devices to support. Those
not specified in the config, won't get initialized and will not service
user's requests.
Additionally, each device manager can now receive its own configuration
in its init() method.
The device configuration is structured as a list of objects with two
properties: "name" and "params". The former identifies a device to
enable, while the latter contains a set of options (if any) specific to
that device manager. For instance:
```
devices:
- name: 'nvmf-tcp'
params:
max_queue_depth: 256
io_unit_size: 8192
- name: 'nvmf-vfiouser'
```
Signed-off-by: Konrad Sztyber <konrad.sztyber@intel.com>
Change-Id: I967016502ad93c243b3a7af58992bde14c44953c
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/11713
Community-CI: Broadcom CI <spdk-ci.pdl@broadcom.com>
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Reviewed-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com>
This patch adds support for loading configuration from a yaml-formatted
file. The command-line options takes precedence over those from the
config file.
Signed-off-by: Konrad Sztyber <konrad.sztyber@intel.com>
Change-Id: Iafb5b4aec0a64afe358fce2d6c55361fc4093223
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/11712
Community-CI: Broadcom CI <spdk-ci.pdl@broadcom.com>
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Karol Latecki <karol.latecki@intel.com>
Reviewed-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Reviewed-by: Monica Kenguva <monica.kenguva@intel.com>
It's now possible to register SMA device managers defined in a module
outside of the regular directory. To do that, a global variable called
`devices` containing a list of device manager classes needs to be defined
in a module that's added to SMA_PLUGINS environment variable.
For example:
```
$ cat /path/to/plugins/external_devices/__init__.py
import spdk.sma as sma
class MyDeviceManager1(sma.DeviceManager):
pass
class MyDeviceManager2(sma.DeviceManager):
pass
devices = [MyDeviceManager1, MyDeviceManager2]
$ SMA_PLUGINS=external_devices scripts/sma.py
```
Multiple plugins can be specified by separating them with a colon, e.g.:
```
SMA_PLUGINS=plugin1:plugin2
```
Of course, the location at which these modules reside must be in
PYTHONPATH.
Signed-off-by: Konrad Sztyber <konrad.sztyber@intel.com>
Change-Id: I2bb4cfea5191710f97d66abe3a21e4deacc6338a
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/11412
Community-CI: Broadcom CI <spdk-ci.pdl@broadcom.com>
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
It's now possible to specify the gRPC interface listen address and the
SPDK-RPC socket path.
Change-Id: I957cf4ca4e03eac6f4f6f7ffab5ee95c5b6f7521
Signed-off-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com>
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/10979
Community-CI: Broadcom CI <spdk-ci.pdl@broadcom.com>
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Storage Management Agent is a gRPC server that provides an abstraction
layer above the SPDK RPC interface. The interface aims to provide a set
of methods for managing various protocols (e.g. NVMe, virtio-blk) while
hiding the details of a particular transport.
The external API is defined by `lib/python/spdk/sma/proto/sma.proto`
protobuf file. It defines the generic gRPC service methods and their
requests/responses. Device-specific messages are defined in their own
files. This patch also defines messages for creating NVMe and NVMe/TCP
devices.
This patch implements a gRPC service that delegates the work to a
specific device type. A DeviceManager is a class that implements some
of the methods defined by the service for a given type of devices (e.g.
NVMe, virtio-blk, NVMe/TCP, etc.). For now, only the RPC for creating a
device is implemented, others are added in subsequent patches.
The series implements the generic calls as well as their NVMe/TCP
implementation. Support for other devce types could be easily added by
creating a new device manager and defining its protobuf parameter
definition.
Signed-off-by: Konrad Sztyber <konrad.sztyber@intel.com>
Change-Id: I17cde3b31d3514878f1027cfcd112b48848f6123
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/10273
Community-CI: Broadcom CI <spdk-ci.pdl@broadcom.com>
Community-CI: Mellanox Build Bot
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
