The NVMe PCIe transport only requires physically contiguous allocations
for struct nvme_tracker and the I/O SQ and CQ entries, which are already
handled separately. Change the comments to indicate that struct
nvme_payload's contiguous type only requires the memory to be virtually
contiguous, since nvme_pcie_prp_list_append() already steps through the
buffer and translates each (4K) page independently.
Change-Id: I45ac8dfb2c033a0fcbf2effbe33af4efc1eb23cb
Reported-by: Dariusz Stojaczyk <dariuszx.stojaczyk@intel.com>
Signed-off-by: Daniel Verkamp <daniel.verkamp@intel.com>
Reviewed-on: https://review.gerrithub.io/417045
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Pawel Wodkowski <pawelx.wodkowski@intel.com>
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
Reviewed-by: Dariusz Stojaczyk <dariuszx.stojaczyk@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
The IOAT "ring" is actually just a circular linked list of descriptors;
the descriptors do not need to be in a single physically contiguous
region. This can be accomodated by calling spdk_vtophys() on each
descriptor rather than assuming they are all in a single contiguous
region.
Also store the physical address of each descriptor in its associated
software descriptor context to avoid the need to call spdk_vtophys()
during runtime.
Change-Id: Ic8636bbc61deb496a0c6d0ea56b75d298f5f426c
Signed-off-by: Daniel Verkamp <daniel.verkamp@intel.com>
Reviewed-on: https://review.gerrithub.io/417782
Reviewed-by: Dariusz Stojaczyk <dariuszx.stojaczyk@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Print an error message instead. The driver can still do
a manual rescan if it wants to see the new SCSI target.
Change-Id: Ieb76ada8625bf00ad068a791b860e4b08ad5cb83
Signed-off-by: Dariusz Stojaczyk <dariuszx.stojaczyk@intel.com>
Reviewed-on: https://review.gerrithub.io/417268
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
Reviewed-by: Pawel Wodkowski <pawelx.wodkowski@intel.com>
Reviewed-by: Daniel Verkamp <daniel.verkamp@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Change-Id: I9e7ff07de8b06afb45b1059d455c8fe854035640
Signed-off-by: Daniel Verkamp <daniel.verkamp@intel.com>
Reviewed-on: https://review.gerrithub.io/417783
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
Also make it correctly account for alignment and automatically
use the internal iov element if necessary.
Change-Id: I0b33ef9444f0693c2d6b0cdaf221c4a5b0ad2cc3
Signed-off-by: Ben Walker <benjamin.walker@intel.com>
Reviewed-on: https://review.gerrithub.io/416870
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 potentially useful for more types of commands.
Change-Id: Ifbde7ae35294f581b8360891579836fd6f9573a6
Signed-off-by: Ben Walker <benjamin.walker@intel.com>
Reviewed-on: https://review.gerrithub.io/416869
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 makes it possible to build SPDK on a machine which doesn't have
CUnit installed.
Change-Id: Icb4c01092d1432fcff4bdbbfa01489d1ddfcdd8b
Signed-off-by: Mike Playle <mplayle@solarflare.com>
Reviewed-on: https://review.gerrithub.io/417663
Reviewed-by: Daniel Verkamp <daniel.verkamp@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
In our current code, when we call the following statement:
spdk_bdev_destruct_done(&lun->bdev, 0);
Actually lun is already freed in bdev_iscsi_lun_cleanup function
(called by iscsi_free_lun). So this patch can be used to
prevent this issue by changing the order.
Change-Id: I5ec02319b8205fafc4d8074511f5a334b9bbb3ad
Signed-off-by: Ziye Yang <optimistyzy@gmail.com>
Reviewed-on: https://review.gerrithub.io/417630
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Poll it every 50 microseconds.
Reason: Ceph's librbd service is not very fast.
So choose a timer period to poll it, instead of
use the syscall to poll it again and again, it
is unnecessary. And this is a default value,
which can be tuned by customers later.
Change-Id: I91c31442da5ddadf3bef43083bd789d01bb1c952
Signed-off-by: Ziye Yang <optimistyzy@gmail.com>
Reviewed-on: https://review.gerrithub.io/417442
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
This code was created when spdk_pci_device wasn't
available yet. Now we can use spdk_pci_device* instead
of void* for extra code clarity.
Change-Id: I81d440720b22a484ae3d2739e0510a021bebbafe
Signed-off-by: Dariusz Stojaczyk <dariuszx.stojaczyk@intel.com>
Reviewed-on: https://review.gerrithub.io/416995
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: Jim Harris <james.r.harris@intel.com>
Since delete_bdev should be used only for debug purpose,
this patch adds delete call specific for passthru bdev.
Signed-off-by: Maciej Szwed <maciej.szwed@intel.com>
Change-Id: I8ea20b3003dd6539d84123c3b5363bd8bdfd6f7f
Reviewed-on: https://review.gerrithub.io/416535
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: Jim Harris <james.r.harris@intel.com>
Since delete_bdev should be used only for debug purpose,
this patch adds delete call specific for pmem bdev.
Signed-off-by: Maciej Szwed <maciej.szwed@intel.com>
Change-Id: Ic526e9ae462f595c4668c2b2612ad074208a7c4e
Reviewed-on: https://review.gerrithub.io/416520
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: Jim Harris <james.r.harris@intel.com>
Since delete_bdev should be used only for debug purpose,
this patch adds delete call specific for rbd bdev.
Signed-off-by: Maciej Szwed <maciej.szwed@intel.com>
Change-Id: Ia87459e0cc49a0c408de582bd1f5680c570d42d9
Reviewed-on: https://review.gerrithub.io/416529
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: Jim Harris <james.r.harris@intel.com>
Since delete_bdev should be used only for debug purpose,
this patch adds delete call specific for null bdev.
Changes in spdkcli done accordingly.
Signed-off-by: Maciej Szwed <maciej.szwed@intel.com>
Change-Id: I576322257e5cf70ec03d6b20f8ba43bfce222907
Reviewed-on: https://review.gerrithub.io/416505
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: Daniel Verkamp <daniel.verkamp@intel.com>
IO channel for LUN is used for hot removal as it is emphasized in the
previous patches.
In iSCSI, a SCSI device has multiple LUNs. So freeing only the IO channel
of a LUN must be possible.
Change-Id: I5b355200b4e173512a5aa4b7351534faf8839eef
Signed-off-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Reviewed-on: https://review.gerrithub.io/417197
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Reviewed-by: Daniel Verkamp <daniel.verkamp@intel.com>
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
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>
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>
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 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>
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>
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>
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>
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>
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>
instead of hitting S11 on event
Change-Id: I7af2a1961bf2c05005a23c3f50eadbcd23e7e38f
Signed-off-by: Leonid Ravich <Leonid.Ravich@dell.com>
Reviewed-on: https://review.gerrithub.io/416972
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>
spdk_thread is recommended to be used in SPDK library.
Change-Id: I5b75f390ddb2069e1266a3fc4f28732b281df725
Signed-off-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Reviewed-on: https://review.gerrithub.io/416482
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: Ziye Yang <optimistyzy@gmail.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
IO channel is freed unexpectedly at LUN removal. This hides
error due to uncorrect implementation of LUN hot removal.
IO channel of LUN must be freed only by its allocator.
Change-Id: Id3721180422364dfc4d9309f3a22ce0a3f766f82
Signed-off-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Reviewed-on: https://review.gerrithub.io/416318
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>
if the scsi status of the task is not GOOD, iscsi_transfer_in() returns
immediately. Hence checking it again is not necesasry.
Change-Id: I55cb025e97c8dcd51692303d0d21ce48b1185631
Signed-off-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Reviewed-on: https://review.gerrithub.io/416315
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: Dariusz Stojaczyk <dariuszx.stojaczyk@intel.com>
Reviewed-by: Ziye Yang <optimistyzy@gmail.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Also report that the NVMe-oF target does not support Flush with the
broadcast NSID.
Change-Id: Iad761a6f81eb099940463a67074a6dccb8871b70
Signed-off-by: Daniel Verkamp <daniel.verkamp@intel.com>
Reviewed-on: https://review.gerrithub.io/416445
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>
