This bug was preventing multiple calls to spdk_nvme_probe() from
working, since the first call would return 0 from all of the DPDK driver
init callbacks and prevent other devices from ever being enumerated in
subsequent calls.
Reported-by: Tsuyoshi Uchida <tuchida@us.fujitsu.com>
Change-Id: I871aa170bbd03be111604eeabe3a7a7a4f40ce89
Signed-off-by: Daniel Verkamp <daniel.verkamp@intel.com>
Use the standard quirk mechanism to specify which devices
need software assisted striping.
Change-Id: Id8156876a90b4caf9d687637e14c7ad4a66ceda6
Signed-off-by: Ben Walker <benjamin.walker@intel.com>
This way, all new controllers discovered will be initialized
in parallel.
Change-Id: Iebedb3905eb2787a3708f74425afae40ca31253d
Signed-off-by: Ben Walker <benjamin.walker@intel.com>
If the first call to spdk_nvme_probe probes a device and
the driver elects not to take it, still call the probe
callback for that device on subsequence calls to
spdk_nvme_probe.
Change-Id: If06467cf6796c827a0bbfba6e36d5b91534526fc
Signed-off-by: Ben Walker <benjamin.walker@intel.com>
Move this down a level so it happens on all paths.
Change-Id: Iea9913f0e102353882466c8dea4ee39abb857520
Signed-off-by: Ben Walker <benjamin.walker@intel.com>
Scanning the transport may result in both new
devices and removed devices, so pass the callback
for both operations.
Change-Id: I6f73dbe6fd7cf61575c354b43f8ae3e2a01e2965
Signed-off-by: Ben Walker <benjamin.walker@intel.com>
Simplify the arguments to nvme_transport_ctrlr_scan to take
a transport id that identifies the discovery service (or
NULL to scan PCIe).
Further, separate scan into two functions - scan and attach.
Scan is for scanning an entire bus, attach is for a specific
device.
Change-Id: I464f351a02a04bc5a45096dcf5dc8fc5ac489041
Signed-off-by: Ben Walker <benjamin.walker@intel.com>
Instead of repeating the fields, just embed a transport_id.
Change-Id: I282704c9d59784abd5f7c93be4e47c673fcf6dde
Signed-off-by: Ben Walker <benjamin.walker@intel.com>
This is a small step toward making discovery more like
scanning a local PCI bus.
Change-Id: Ie7149ad060f2eeb56939b1241187bdf09681f2aa
Signed-off-by: Ben Walker <benjamin.walker@intel.com>
Before adding readv/writev support in nvme_rdma,
using this patch.
Change-Id: I25ff0df61d0346f22560d011158d7f80e72007ea
Signed-off-by: Ziye Yang <ziye.yang@intel.com>
NUMDU was added with NVMe 1.2.1 and allows a larger log page size to be
described.
Change-Id: I1a4ac42393c1a21175b3564980d56b6e7a6ae80d
Signed-off-by: Daniel Verkamp <daniel.verkamp@intel.com>
The NVMe over Fabrics transports should already be setting this in the
initial admin queue Connect command, so setting it again is not useful.
The kernel NVMe over Fabrics target additionally has a bug in the Set
Features - Keep Alive Timeout handler (it is extracting the KATO value
from the wrong offset in the command), so this works around the kernel
bug by not sending the Set Features command at all.
Change-Id: I0d7f09b71fcea116acf8810c5880157bb9315a04
Signed-off-by: Ziye Yang <ziye.yang@intel.com>
The reason is that kernel nvmf target will check the
value. If not set, it will fail the other commands later.
Even for discovery ctrlr, kernel nvmf target will
check the cc value.
Change-Id: I998327f91ba96281d261952878eb84d648a823da
Signed-off-by: Ziye Yang <ziye.yang@intel.com>
It's not the whole transport - it's just an enum for the
type of transport.
Change-Id: Ia435a21792f221ddf50ddf4f0923c6152622eccb
Signed-off-by: Ben Walker <benjamin.walker@intel.com>
Change it according to the spec thus we can test
kernel nvmf target
Change-Id: Ica98dd40503a40c0f0de8efaefb1f6f67a89cde8
Signed-off-by: Ziye Yang <ziye.yang@intel.com>
Change the PCI enumeration API to individual functions per device type
so that only the drivers that are actually in use get linked into the
final executable. All of the common code is still shared internally in
the env_dpdk library.
Change-Id: I2ba83afe59202a510f999a0674e23e60b6581221
Signed-off-by: Daniel Verkamp <daniel.verkamp@intel.com>
The user's remove_cb should detach the NVMe controller when it can
ensure that it is no longer in use. In the interim (between remove_cb
and spdk_nvme_detach()), the controller will remain in a failed state,
so any new I/O submissions will return an error code but not crash.
examples/nvme/hotplug is not yet updated for this change, but that will
be done in a separate patch.
Change-Id: I8827ba36f9688ccb734e7871f20f11ec11e88f96
Signed-off-by: Daniel Verkamp <daniel.verkamp@intel.com>
While we're here, fix up typos and add error logs for all error exits
in nvme_rdma_qpair_connect().
Change-Id: I236fe6571c2012ca047aa8a447638d9227454c2f
Signed-off-by: Daniel Verkamp <daniel.verkamp@intel.com>
This version of multi-process support needs to have DPDK 16.11 builtin.
Change-Id: I3352944516f327800b4bd640347afc6127d82ed4
Signed-off-by: GangCao <gang.cao@intel.com>
The discover and probe 'nqn' fields are subsystem NQNs, so name them
subnqn to be consistent with the spec and the rest of the code and to
distinguish them from host NQNs.
Change-Id: I4a80fbc1f4b037c8a4f91c8f28d2a96e47c66c47
Signed-off-by: Daniel Verkamp <daniel.verkamp@intel.com>
Allow the host NQN to be overriden when connecting to NVMe over Fabrics
controllers.
Change-Id: I8fcf2e89ae7d9722677e834f76a8fe805c52f91b
Signed-off-by: Daniel Verkamp <daniel.verkamp@intel.com>
This makes the function and file/line info actually useful (instead of
pointing to the helper function itself).
Change-Id: I22bac68827115880a49d456706a7eaecdc12e9b5
Signed-off-by: Daniel Verkamp <daniel.verkamp@intel.com>
Each transport should handle its own qpair cleanup internally.
Change-Id: I7dd737be820ea6bad686f4aad7d74044fad58a47
Signed-off-by: Daniel Verkamp <daniel.verkamp@intel.com>
Let the transport access the controller options during
ctrlr_construct().
Change-Id: I83590c111e75c843685dd9315f0f08416168356d
Signed-off-by: Daniel Verkamp <daniel.verkamp@intel.com>
nvme_rdma_req_get() is an internal function, and its only caller already
checks for a valid rqpair, so the NULL check is unnecessary.
Also clean up the redundant STAILQ_EMPTY/STAILQ_FIRST logic and use
STAILQ_REMOVE_HEAD.
Change-Id: Ic3828e8b5e881879173cb59350e39c5fac90e6ef
Signed-off-by: Daniel Verkamp <daniel.verkamp@intel.com>
nvme_rdma_pre_copy_mem() does not have any failure cases, so remove its
return value and remove the never-taken branch in its only caller,
nvme_rdma_qpair_submit_request().
Change-Id: I91011734ed0c20f8db691d62172fe1a3021dd3a1
Signed-off-by: Daniel Verkamp <daniel.verkamp@intel.com>
nvme_rdma_req_put() is an internal nvme_rdma.c function, and all of the
callers already have the rqpair, so pass it directly. We also already
verify that all of the callers have a valid rqpair and req before
calling nvme_rdma_req_put(), so it doesn't need to check for NULL
pointers.
This also means that spdk_nvme_rdma_req doesn't need to hold a pointer
to its rqpair anymore.
Change-Id: I893a46a9074f0a843e379d10c123f9292eb3b1a4
Signed-off-by: Daniel Verkamp <daniel.verkamp@intel.com>
The only place where outstanding_reqs was checked was in
nvme_rdma_req_put(), but the error case there could only happen if some
kind of internal programming error occurred (e.g. calling
nvme_rdma_req_put() on an invalid request).
Change-Id: I71e40ce562a8720dfaf70437ffd4c6493327c091
Signed-off-by: Daniel Verkamp <daniel.verkamp@intel.com>
nvme_rdma_ibv_send_wr_init() was only called in one place, so just move
its contents into nvme_rdma_qpair_submit_request() since it allows
simplification of the code:
- req was always NULL, so remove the code that used req entirely.
- wr and sg_list are never NULL, so remove the checks for those.
Change-Id: I12a4f3502219d3681607686945e343f6808c0d2f
Signed-off-by: Daniel Verkamp <daniel.verkamp@intel.com>
We currently don't handle discovery service referrals, so skip those, as
well as any other unknown subsystem type.
Change-Id: I64f889e9272fb57b5cf9bb5467b3abca3955baf5
Signed-off-by: Daniel Verkamp <daniel.verkamp@intel.com>
QEMU's virtual NVMe controller device does not support the AER Set
Feature, so ignore its failure and continue.
Change-Id: I8b5c217a3112edabb6f76ec3e5f4ef774981a1d7
Signed-off-by: Cunyin Chang <cunyin.chang@intel.com>
