Enables us to test randomized data against the NVMe-oF target interface.
Change-Id: Ie7ab46949ccd89f74b10b79a24256aeae2df89ab
Signed-off-by: Seth Howell <seth.howell@intel.com>
Reviewed-on: https://review.gerrithub.io/c/spdk/spdk/+/431571
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Hailiang Wang <hailiangx.e.wang@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Reviewed-by: qun wan <qun.wan@intel.com>
Reviewed-by: Darek Stojaczyk <dariusz.stojaczyk@intel.com>
This allows us to query and configure the bdev
modules much more dynamically.
Change-Id: I11f757039892f4353721be422317b641d72bd2a9
Signed-off-by: Ben Walker <benjamin.walker@intel.com>
Reviewed-on: https://review.gerrithub.io/370584
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Daniel Verkamp <daniel.verkamp@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Starting SPDK applications can take a long time due to
two factors: DPDK memory initialization and NVMe
device initialization.
This stub application facilitates eliminating those
delays by leveraging DPDK's multi-process mode. This
stub application acts as the primary process,
initializing DPDK as well as all NVMe devices bound
to userspace modules (uio/vfio). Then another
SPDK process can be started using the same instance
ID, which will make that SPDK process a secondary
process of the stub and leverage the DPDK memory and
NVMe device initialization already performed by the
primary process.
To start this will be used to accelerate the iSCSI
system level tests (in test/iscsi_tgt) to significantly
reduce test time in the CI pool.
Signed-off-by: Jim Harris <james.r.harris@intel.com>
Change-Id: I3019c7d883f40b3ee8fb3345db013df2afc25645
Reviewed-on: https://review.gerrithub.io/362453
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
