Reorder operations of LUN hot removal so that following are satisfied.
Wait for completion of all outstanding tasks first. (After turning lun->removed
on, there will be no new outstanding task.)
Then wait for IO channel being freed. (For VHOST SCSI, IO channel is freed
in the callback handler of hot removal. For iSCSI, IO channel is freed when
the final connection exits. IO channel of LUN is freed only by the allocator.)
Then free LUN finally.
For VHOST SCSI, the callback handler of hot removal will
call spdk_scsi_lun_destruct() in spdk_scsi_dev_destruct(). But lun->removed is
already turned on and spdk_scsi_lun_hot_remove() will be NOP. Hence LUN is
freed safely by the first caller of spdk_scsi_lun_hot_remove().
Change-Id: I276dfed1d4a7767e382003bd9bb389aaff920115
Signed-off-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Reviewed-on: https://review.gerrithub.io/417196
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Change-Id: I21139603dce30a242e49b2fcc8c4152613369f44
Signed-off-by: Tomasz Kulasek <tomaszx.kulasek@intel.com>
Reviewed-on: https://review.gerrithub.io/413255
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>
Reviewed-by: John Kariuki <John.K.Kariuki@intel.com>
Reviewed-by: Maciej Szwed <maciej.szwed@intel.com>
Reviewed-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com>
Signed-off-by: <tomaszx.kulasek@intel.com>
Change-Id: Ib3516b85a721363526deab14170da87a8d9232f1
Reviewed-on: https://review.gerrithub.io/415298
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>
We don't support the kernel vhost. Vhost-SCSI is not even
fully implemented in Linux, so there's no point trying.
Change-Id: Ie564d46c497718081dd2a5c28829fdcf88e1c0a0
Signed-off-by: Dariusz Stojaczyk <dariuszx.stojaczyk@intel.com>
Reviewed-on: https://review.gerrithub.io/417455
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>
This fixes intermittent failures with QEMU's virtio-scsi-pci
device.
Apparently, from time to time QEMU enters a broken state in
which it doesn't turn off the NO_NOTIFY flag. This flag should
be set only for the period of time virtqueues are being processed,
but QEMU makes it set all the time. This makes us not signal any
I/O submissions - SPDK thinks the device is currently processing
notifications so it will pick up our I/O automatically, but in
realitly it won't and we end up with a deadlock.
I believe kernel virtio driver doesn't hit this issue because of
event index feature. If negotiated, the NO_NOTIFY flag won't be
used at all. Initial tests show that the issue is indeed gone
with this patch.
Event index for SPDK virtio is not particularly useful when using
a poll-mode device, but it doesn't do any harm. It can be further
optimized in the future, but macro-benchmarks don't show any
performance difference compared with the legacy notification
handling so there's no hurry.
Change-Id: I46e8ab0da170780fcdc0dd239208670ee5ed6357
Signed-off-by: Dariusz Stojaczyk <dariuszx.stojaczyk@intel.com>
Reviewed-on: https://review.gerrithub.io/415591
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
Reviewed-by: Pawel Wodkowski <pawelx.wodkowski@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
With upcoming event index patch we will need
to keep track of how many descriptor chains we
have really put into the avail vring. This patch
is a step towards that.
Our virtio layer abstracts away descriptor chains
as "requests". We can start requests, add descriptors
to them, and finally flush them. So far we used to put
any descriptors directly into the virtqueue desc ring,
and made them visible to the device only through
virtqueue_req_flush().
All of our virtio bdev modules currently flush the
virtqueue after adding each single request, but the
docs for the virtio API say it's possible to start
multiple subsequent requests and flush them all at
once. This was conceptually broken so far and only
the last request would be exposed to the device.
It's now fixed and subsequent requests are put
into the avail vring as soon as they're complete
(either the next request is started, or the
virtqueue is flushed).
Change-Id: I76b7db88ab094c38430edd8ff0e65681775dcb31
Signed-off-by: Dariusz Stojaczyk <dariuszx.stojaczyk@intel.com>
Reviewed-on: https://review.gerrithub.io/415590
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Daniel Verkamp <daniel.verkamp@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
There's no need to split a bufffer if it's physically
contiguous. We can now merge buffers that would be
previously split by the nvme_pcie driver and also
separate SGEs provided by the user that happen to be
physically contiguous.
Change-Id: I9c9de31d52a9dc9e384806555cb94609aff0ccf3
Signed-off-by: Dariusz Stojaczyk <dariuszx.stojaczyk@intel.com>
Reviewed-on: https://review.gerrithub.io/417061
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Reviewed-by: Daniel Verkamp <daniel.verkamp@intel.com>
This allows NVMe PCIe devices to be used with
physically discontiguous I/O payload buffers.
So far this is just a dumb splitting which
doesn't check for physical contiguity. This is
improved in a subsequent patch.
Change-Id: I0ecc443149225eaa0e4156ddda78613bcf034406
Suggested-by: Daniel Verkamp <daniel.verkamp@intel.com>
Signed-off-by: Dariusz Stojaczyk <dariuszx.stojaczyk@intel.com>
Reviewed-on: https://review.gerrithub.io/417060
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Daniel Verkamp <daniel.verkamp@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
DPDK memzone name limit is 32 and mempool's 29 as it
internally reserves a memzone with "MP_" prefix.
DPDK also offers defines for those limits, but we
obviously can't use them in generic env header file.
Change-Id: I16abcf404eee390a9033135e996cba1716baca5f
Signed-off-by: Dariusz Stojaczyk <dariuszx.stojaczyk@intel.com>
Reviewed-on: https://review.gerrithub.io/416979
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
This is an spdk_memzone_reserve variant with additional
alignment parameter. Now that memzones must be used for
physically contiguous memory, it will become extremely useful.
Change-Id: Ie48d682217e0e2f5c859a1603bb8a81fd2a7d7df
Signed-off-by: Dariusz Stojaczyk <dariuszx.stojaczyk@intel.com>
Reviewed-on: https://review.gerrithub.io/416978
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Reviewed-by: Daniel Verkamp <daniel.verkamp@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Future DPDK versions may drop physical memory contiguity
guarantee for common memzones. DPDK 18.05 introduces
an RTE_MEMZONE_IOVA_CONTIG (0x00100000) flag, which is
documented as follows:
> RTE_MEMZONE_IOVA_CONTIG - Ensure reserved memzone is IOVA-contiguous.
> This option should be used when allocating
> memory intended for hardware rings etc.
To preserve backward compatibility, SPDK introduces an opposite
flag, SPDK_MEMZONE_NO_IOVA_CONTIG.
Change-Id: I9ea79b096fdb094051f13c9a802740b0e4ccc98e
Signed-off-by: Dariusz Stojaczyk <dariuszx.stojaczyk@intel.com>
Reviewed-on: https://review.gerrithub.io/416977
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Daniel Verkamp <daniel.verkamp@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
This is the more appropriate location for this test
Change-Id: If556b365975f5658a55924aeb7122186961972bd
Signed-off-by: Ben Walker <benjamin.walker@intel.com>
Reviewed-on: https://review.gerrithub.io/417365
Reviewed-by: Daniel Verkamp <daniel.verkamp@intel.com>
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
This exposes that one of the tests was not expecting
the correct behavior, so also fix that.
Change-Id: Idb73b3ea74950b2e6f959a40e5740375cb76b8c7
Signed-off-by: Ben Walker <benjamin.walker@intel.com>
Reviewed-on: https://review.gerrithub.io/417364
Reviewed-by: Daniel Verkamp <daniel.verkamp@intel.com>
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
This const makes the array passed in immutable, but that
isn't helpful or interesting since it just contains
invalid pointer addresses. It may also make sense in the
future to NULL out the addresses in the array in a debug
build. So drop the const.
Change-Id: I921551c7cb1dbf6c765fb301c31906b8b93b7f16
Signed-off-by: Ben Walker <benjamin.walker@intel.com>
Reviewed-on: https://review.gerrithub.io/417362
Reviewed-by: Daniel Verkamp <daniel.verkamp@intel.com>
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
spdk_bdev_read() bdev function is not used
in scsi library. No need to stub it.
Change-Id: I7c142c59c5e64ae9ecfabaf0c73a9b0e68fffd04
Signed-off-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com>
Reviewed-on: https://review.gerrithub.io/417550
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Daniel Verkamp <daniel.verkamp@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
There's currently no way to issue only fills unless
the app is slightly modified. Nevertheless, this
patch makes the code more readable.
Change-Id: I15a6ed57ed06880d26970c4be7c2db3b7326d3d4
Signed-off-by: Dariusz Stojaczyk <dariuszx.stojaczyk@intel.com>
Reviewed-on: https://review.gerrithub.io/416660
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Reviewed-by: Daniel Verkamp <daniel.verkamp@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
This was obviously omitted in the original implementation.
Change-Id: Ifba049cdb8d1c1f24e30adb542946a2fa83c7464
Signed-off-by: Dariusz Stojaczyk <dariuszx.stojaczyk@intel.com>
Reviewed-on: https://review.gerrithub.io/416655
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Reviewed-by: Daniel Verkamp <daniel.verkamp@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
We're usually lucky and either the buffer is physically-contiguous,
or the address is already 8-bit aligned, but intermittent failures
were still happening. Not anymore.
Change-Id: Iec226b42f66c7c273f181cda764b92164e24b0e3
Signed-off-by: Dariusz Stojaczyk <dariuszx.stojaczyk@intel.com>
Reviewed-on: https://review.gerrithub.io/416658
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Reviewed-by: Daniel Verkamp <daniel.verkamp@intel.com>
void* arithmetics are gcc extension. We'll be doing
more complex arithmetics on those pointers soon and
gcc will explode on us. Let's just keep it all
compliant to the C standard.
Change-Id: I9a236fc4d91ff72af1b7ac69b0ccf6b4631a6775
Signed-off-by: Dariusz Stojaczyk <dariuszx.stojaczyk@intel.com>
Reviewed-on: https://review.gerrithub.io/416656
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Daniel Verkamp <daniel.verkamp@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
- load spdk_tgt with bdevs
- check if json config is properly saved and loaded
- check if all bdevs are properly loaded
- check if configuration of spdk_tgt is properly set
Change-Id: I89226bc9c05880e73523fb189116e7433a513244
Signed-off-by: Pawel Kaminski <pawelx.kaminski@intel.com>
Reviewed-on: https://review.gerrithub.io/406326
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Pawel Wodkowski <pawelx.wodkowski@intel.com>
Reviewed-by: Daniel Verkamp <daniel.verkamp@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
The astyle check warns if it is missing; we should do the same for
pycodestyle so that the user is aware that some checks are being
skipped.
Change-Id: I0709a2acaab7bcb5184e7f302d37822a124d6769
Signed-off-by: Daniel Verkamp <daniel.verkamp@intel.com>
Reviewed-on: https://review.gerrithub.io/416761
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
pep8 has been renamed to pycodestyle; check for pycodestyle first so
that we prefer the up-to-date version over the deprecated pep8 name.
Change-Id: Ie9cf2d0c156885893926358cfb546432ad38f23d
Signed-off-by: Daniel Verkamp <daniel.verkamp@intel.com>
Reviewed-on: https://review.gerrithub.io/416760
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
This was missed when splitting thread into its own library; the thread
symbols were missing from libspdk.so.
Change-Id: Ibcd1ea8cc5be1340cc4b848c81b4c92b036675a8
Fixes: 02d75f6237c8 ("thread: Move threading abstraction code out of util")
Fixes: 6f46e272c3c0 ("build: add combined shared library (libspdk.so)")
Signed-off-by: Daniel Verkamp <daniel.verkamp@intel.com>
Reviewed-on: https://review.gerrithub.io/417171
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
The norandommap and verify parameter are mutually exclusive.
So add norandommap variable in fio template. If verify is enabled,
the norandommap is zero.
Change-Id: I60a82ee561a3ae9fa94a58c00a35576f60fbc185
Signed-off-by: Liang Yan <liang.z.yan@intel.com>
Reviewed-on: https://review.gerrithub.io/417094
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Daniel Verkamp <daniel.verkamp@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Within the bdev layer, we want to know specifically what I/O
types the module supports. However, the bdev module may elect
to emulate some commands and report additional support via
the public API.
The bdev layer already emulates WRITE_ZEROES, so correctly
report that fact.
Change-Id: I79bfb1aee1b3e6048f951bb1b2c7d4f7c9ef184d
Signed-off-by: Ben Walker <benjamin.walker@intel.com>
Reviewed-on: https://review.gerrithub.io/416464
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Reviewed-by: Daniel Verkamp <daniel.verkamp@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
The only purpose at the moment is to allow vendoring of the SPDK
source code into Go projects which manage dependencies with the "dep"
tool. That tool is designed for Go projects and as a sanity check
rejects any dependency which does not have at least one Go file, at
least at the moment (https://github.com/golang/dep/issues/1306).
Change-Id: I22458d0895729ad7d8ea53e7541e9089da1d448a
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Reviewed-on: https://review.gerrithub.io/416831
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Daniel Verkamp <daniel.verkamp@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Save the original size of the disk to metadata when it is first created.
On load verify that the disk did not change size.
Signed-off-by: Piotr Pelplinski <piotr.pelplinski@intel.com>
Change-Id: I535940ee188425ee3b394effd99653cc073d541e
Reviewed-on: https://review.gerrithub.io/410896
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Daniel Verkamp <daniel.verkamp@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Newer versions of scan-build complain about cb_fn potentially being null
in spdk_bdev_unregister.
Change-Id: Ib5607234557f2104ee30398a620fa595389a33e9
Signed-off-by: Seth Howell <seth.howell@intel.com>
Reviewed-on: https://review.gerrithub.io/417064
Reviewed-by: Daniel Verkamp <daniel.verkamp@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Change-Id: Id3eaf1d0a4216d0bea618821ffe5456f4e07f4b9
Signed-off-by: Liang Yan <liang.z.yan@intel.com>
Reviewed-on: https://review.gerrithub.io/416917
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Reviewed-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com>
Reviewed-by: Daniel Verkamp <daniel.verkamp@intel.com>
When spdk_for_each_channel() was called on an io_device with no
channels, the completion function would be called immediately in the
context of the spdk_for_each_channel() caller. This is different than
the normal completion when channels are present, which is always called
asynchronously via spdk_thread_send_msg(), causing problems for callers
that did not expect to get the completion callback before
for_each_channel returned.
In particular, this causes problems with the set_bdev_qos_limit_iops RPC
method, which holds a mutex around the spdk_for_each_channel() call and
also attempts to lock that mutex again within the completion callback.
(This is GitHub issue #344.)
To avoid this problem and make the completion call consistent between
no-channels and channels-present cases, always send the completion via
spdk_thread_send_msg().
Change-Id: I9e5ec3592462c7b2ed682e665fe62ae3a5b5cc59
Signed-off-by: Daniel Verkamp <daniel.verkamp@intel.com>
Reviewed-on: https://review.gerrithub.io/417068
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
The name of the rpm source for open-iscsi changes between fedora
releases. Also, there was a typo on the tsocks check.
Change-Id: I0f9810c51c35c3efd5616fad303d08b02d9e2218
Signed-off-by: Seth Howell <seth.howell@intel.com>
Reviewed-on: https://review.gerrithub.io/416882
Reviewed-by: Daniel Verkamp <daniel.verkamp@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Change-Id: Ia3122d7680e34b2270218a96770b2a2662b732ad
Signed-off-by: Karol Latecki <karol.latecki@intel.com>
Reviewed-on: https://review.gerrithub.io/416526
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Reviewed-by: Daniel Verkamp <daniel.verkamp@intel.com>
Add option in test/vhost/common.sh to run FIO
with --output-format=json
Change-Id: I3115cf35d48a15a539d91e21f8f128970f150467
Signed-off-by: Karol Latecki <karol.latecki@intel.com>
Reviewed-on: https://review.gerrithub.io/416525
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Reviewed-by: Seth Howell <seth.howell5141@gmail.com>
Reviewed-by: John Kariuki <John.K.Kariuki@intel.com>
Reviewed-by: Pawel Wodkowski <pawelx.wodkowski@intel.com>
Reviewed-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com>
Reviewed-by: Daniel Verkamp <daniel.verkamp@intel.com>
This was changed in commit 8f26b74e020a ("examples: make debug flag
option consistent").
Change-Id: Id47eff11321063b684fdd4e9d2187e459065e98e
Signed-off-by: Daniel Verkamp <daniel.verkamp@intel.com>
Reviewed-on: https://review.gerrithub.io/416890
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Same as we do with SPDK_ENV_SOCKET_ID_ANY, memzone
flags should be translated from SPDK defines to their
DPDK equivalents instead of passing those 1:1.
Note that we don't use any memzone flags so far.
Change-Id: I4100dd7ac8825eecd7f323bc21b3b6b8347bfa8d
Signed-off-by: Dariusz Stojaczyk <dariuszx.stojaczyk@intel.com>
Reviewed-on: https://review.gerrithub.io/416976
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Seth Howell <seth.howell5141@gmail.com>
Reviewed-by: Daniel Verkamp <daniel.verkamp@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
This is a generic NVMe-oF command that may be used for other transports.
Change-Id: Id5fbf1f176ef5f75a221b40eff538e693817bcaf
Signed-off-by: Daniel Verkamp <daniel.verkamp@intel.com>
Reviewed-on: https://review.gerrithub.io/416578
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
All controllers have a controller ID (cntlid), and this will be needed
in other NVMe-oF transports, so move it to the generic controller
structure.
Change-Id: Iaba5b93e1267e7bef3a6eb7c677c549a3d83985c
Signed-off-by: Daniel Verkamp <daniel.verkamp@intel.com>
Reviewed-on: https://review.gerrithub.io/416577
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
This can be used for other NVMe-oF transports.
Change-Id: Ic8d2dc483220eb3690cb756bcd750d19c93d98e6
Signed-off-by: Daniel Verkamp <daniel.verkamp@intel.com>
Reviewed-on: https://review.gerrithub.io/416576
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
These functions are generic and may be used for other NVMe-oF
transports.
Change-Id: Idb3aa30d9b0b1be7b60b85ab4911b28db35977a4
Signed-off-by: Daniel Verkamp <daniel.verkamp@intel.com>
Reviewed-on: https://review.gerrithub.io/416575
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
