Re: [SPDK] SPDK Client Demo from the last community meeting
by Meneghini, John
The requested page was not found on this server. Please check the spelling and try again.
Looks like there’s a problem.
/John
From: SPDK <spdk-bounces(a)lists.01.org> on behalf of "Luse, Paul E" <paul.e.luse(a)intel.com>
Reply-To: Storage Performance Development Kit <spdk(a)lists.01.org>
Date: Friday, April 20, 2018 at 10:10 AM
To: Storage Performance Development Kit <spdk(a)lists.01.org>
Subject: [SPDK] SPDK Client Demo from the last community meeting
For those that missed Karol’s demo… here is the streaming video
Thx
Paul
https://intel.webex.com/mw3200/mywebex/nbrshared.do
1 year, 11 months
Re: [SPDK] SPDK Client Demo from the last community meeting
by Meneghini, John
Thanks Paul, for forwarding this.
From: SPDK <spdk-bounces(a)lists.01.org> on behalf of "Luse, Paul E" <paul.e.luse(a)intel.com>
Reply-To: Storage Performance Development Kit <spdk(a)lists.01.org>
Date: Friday, April 20, 2018 at 10:10 AM
To: Storage Performance Development Kit <spdk(a)lists.01.org>
Subject: [SPDK] SPDK Client Demo from the last community meeting
For those that missed Karol’s demo… here is the streaming video
Thx
Paul
https://intel.webex.com/mw3200/mywebex/nbrshared.do
1 year, 11 months
Safe(r) iteration over I/O types
by Andrey Kuzmin
When iterating over I/O types, it looks safer to have a predefined
closing bracket like below
for (enum spdk_bdev_io_type io_type = 0; io_type <
SPDK_BDEV_IO_TYPES; io_type ++)
than to rely on write_zeroes being the last known type (so far). A
trivial patch that adds the bracket is attached below.
Regards,
Andrey
diff --git a/include/spdk/bdev.h b/include/spdk/bdev.h
index 60a2d716..9bab73f3 100644
--- a/include/spdk/bdev.h
+++ b/include/spdk/bdev.h
@@ -97,6 +97,7 @@ enum spdk_bdev_io_type {
SPDK_BDEV_IO_TYPE_NVME_IO,
SPDK_BDEV_IO_TYPE_NVME_IO_MD,
SPDK_BDEV_IO_TYPE_WRITE_ZEROES,
+ SPDK_BDEV_IO_TYPES /* Keep last */
};
1 year, 11 months
EAGAIN handling bad in bdev_aio.c
by Andrey Kuzmin
I've hit the subj when running bdevperf against a bdev_aio target at
qd=512. The patch below tells the story. Let me know if I should raise
an issue (and how to proceed then) or the patch suffices.
Regards,
Andrey
diff --git a/lib/bdev/aio/bdev_aio.c b/lib/bdev/aio/bdev_aio.c
index eca7091b..be10d3f1 100644
--- a/lib/bdev/aio/bdev_aio.c
+++ b/lib/bdev/aio/bdev_aio.c
@@ -131,12 +131,12 @@ bdev_aio_readv(struct file_disk *fdisk, struct
spdk_io_channel *ch,
rc = io_submit(aio_ch->io_ctx, 1, &iocb);
if (rc < 0) {
- if (rc == EAGAIN) {
+ if (rc == -EAGAIN) {
spdk_bdev_io_complete(spdk_bdev_io_from_ctx(aio_task),
SPDK_BDEV_IO_STATUS_NOMEM);
} else {
spdk_bdev_io_complete(spdk_bdev_io_from_ctx(aio_task),
SPDK_BDEV_IO_STATUS_FAILED);
+ SPDK_ERRLOG("%s: io_submit returned %d\n",
__func__, rc);
}
- SPDK_ERRLOG("%s: io_submit returned %d\n", __func__, rc);
return -1;
}
aio_ch->io_inflight++;
@@ -161,12 +161,12 @@ bdev_aio_writev(struct file_disk *fdisk, struct
spdk_io_channel *ch,
rc = io_submit(aio_ch->io_ctx, 1, &iocb);
if (rc < 0) {
- if (rc == EAGAIN) {
+ if (rc == -EAGAIN) {
spdk_bdev_io_complete(spdk_bdev_io_from_ctx(aio_task),
SPDK_BDEV_IO_STATUS_NOMEM);
} else {
spdk_bdev_io_complete(spdk_bdev_io_from_ctx(aio_task),
SPDK_BDEV_IO_STATUS_FAILED);
+ SPDK_ERRLOG("%s: io_submit returned %d\n",
__func__, rc);
}
- SPDK_ERRLOG("%s: io_submit returned %d\n", __func__, rc);
return -1;
}
aio_ch->io_inflight++;
1 year, 11 months
Re: [SPDK] Namespace attribute notification change problem
by Meneghini, John
The fix for this was to update our Fedora 26 kernel from 4.15.6-200.fc26.x86_64 to 4.15.17-200.fc26.x86_64.
Was this a known dependency or bug?
If so, I’d be interested in understanding exactly what the bug was.
Thanks,
/John
From: SPDK <spdk-bounces(a)lists.01.org> on behalf of "Rodriguez, Edwin" <Ed.Rodriguez(a)netapp.com>
Reply-To: Storage Performance Development Kit <spdk(a)lists.01.org>
Date: Thursday, April 19, 2018 at 1:06 PM
To: Storage Performance Development Kit <spdk(a)lists.01.org>
Subject: [SPDK] Namespace attribute notification change problem
We recently updated our repo to the latest master and broke our FC26 autotest systems. I bisected the issue down to this SHA:
[edwinr@ssan-rx2560-01:7]~/p4/SPDK/master/spdk(master)> git show 3165d0c0
commit 3165d0c070a37af45e192cae066f6623612e6bc6
Author: Daniel Verkamp <daniel.verkamp(a)intel.com>
Date: Tue Apr 3 14:32:33 2018 -0700
nvmf: report support for NS Attribute notification
Fixes: 26541489ef92 ("nvmf: implement Get Log Page - Changed NS List")
Fixes: 763ab8888482 ("nvmf: add Namespace attribute notice support")
Change-Id: Id015e4d96fe98a7f6c845821395463e341b7066c
Signed-off-by: Daniel Verkamp <daniel.verkamp(a)intel.com>
Reviewed-on: https://review.gerrithub.io/406247
Tested-by: SPDK Automated Test System <sys_sgsw(a)intel.com>
Reviewed-by: Ben Walker <benjamin.walker(a)intel.com>
Reviewed-by: Jim Harris <james.r.harris(a)intel.com>
diff --git a/lib/nvmf/ctrlr.c b/lib/nvmf/ctrlr.c
index 7981a15e..f8cf4030 100644
--- a/lib/nvmf/ctrlr.c
+++ b/lib/nvmf/ctrlr.c
@@ -1164,6 +1164,7 @@ spdk_nvmf_ctrlr_identify_ctrlr(struct spdk_nvmf_ctrlr *ctrlr, struct spdk_nvme_c
cdata->kas = 10;
cdata->rab = 6;
+ cdata->oaes.ns_attribute_notices = 1;
cdata->ctratt.host_id_exhid_supported = 1;
cdata->aerl = 0;
cdata->frmw.slot1_ro = 1;
I then updated the FC26 machine to the latest available packages, including updating the kernel from 4.15.6-200.fc26.x86_64 to 4.15.17-200.fc26.x86_64 which fixed the problem, however I’m curious why this particular change would have caused a problem.
The error reported was:
09:52:42 # ./app/nvmf_tgt/nvmf_tgt -i 0 -c /x/eng/bbrtp/SPDK-CIT/ssan-rx2560-01/build-20180419093836/spdk/test/nvmf/filesystem/../nvmf.conf
09:52:42 # waitforlisten 31010
09:52:42 # '[' -z 31010 ']'
09:52:42 # rpc_addr=/var/tmp/spdk.sock
09:52:42 # echo 'Waiting for process to start up and listen on UNIX domain socket /var/tmp/spdk.sock...'
Waiting for process to start up and listen on UNIX domain socket /var/tmp/spdk.sock...
09:52:42 # set +x
Starting SPDK v18.04-pre / DPDK 18.02.0 initialization...
[ DPDK EAL parameters: nvmf -c 0xF --file-prefix=spdk0 --base-virtaddr=0x1000000000 --proc-type=auto ]
EAL: Detected 48 lcore(s)
EAL: Auto-detected process type: SECONDARY
EAL: Multi-process socket /var/run/.spdk0_unix_31010_4be0c2c5c82ae6
EAL: Probing VFIO support...
EAL: VFIO support initialized
app.c: 443:spdk_app_start: *NOTICE*: Total cores available: 4
reactor.c: 645:spdk_reactors_init: *NOTICE*: Occupied cpu socket mask is 0x1
reactor.c: 429:_spdk_reactor_run: *NOTICE*: Reactor started on core 1 on socket 0
reactor.c: 429:_spdk_reactor_run: *NOTICE*: Reactor started on core 2 on socket 0
reactor.c: 429:_spdk_reactor_run: *NOTICE*: Reactor started on core 3 on socket 0
reactor.c: 429:_spdk_reactor_run: *NOTICE*: Reactor started on core 0 on socket 0
copy_engine_ioat.c: 318:copy_engine_ioat_init: *NOTICE*: Ioat Copy Engine Offload Enabled
09:52:42 # timing_exit start_nvmf_tgt
09:52:42 # set +x
09:52:42 # python /x/eng/bbrtp/SPDK-CIT/ssan-rx2560-01/build-20180419093836/spdk/scripts/rpc.py construct_malloc_bdev 64 512
09:52:42 # bdevs=' Malloc0'
09:52:42 # python /x/eng/bbrtp/SPDK-CIT/ssan-rx2560-01/build-20180419093836/spdk/scripts/rpc.py construct_malloc_bdev 64 512
09:52:42 # bdevs=' Malloc0 Malloc1'
09:52:42 # modprobe -v nvme-rdma
insmod /lib/modules/4.15.6-200.fc26.x86_64/kernel/drivers/nvme/host/nvme-rdma.ko.xz
09:52:42 # python /x/eng/bbrtp/SPDK-CIT/ssan-rx2560-01/build-20180419093836/spdk/scripts/rpc.py construct_nvmf_subsystem nqn.2016-06.io.spdk:cnode1 'trtype:RDMA traddr:10.63.1.20 trsvcid:4420' '' -a -s SPDK00000000000001 -n ' Malloc0 Malloc1'
09:52:42 # nvme connect -t rdma -n nqn.2016-06.io.spdk:cnode1 -a 10.63.1.20 -s 4420
09:52:43 # mkdir -p /mnt/device
09:52:43 # grep nvme
09:52:43 # lsblk -l -o NAME
09:52:43 # trap - ERR
09:52:43 # print_backtrace
09:52:43 # local shell_options=hxBE
09:52:43 # set +x
========== Backtrace start: ==========
in test/nvmf/filesystem/filesystem.sh:44 -> main()
...
39
40 nvme connect -t rdma -n "nqn.2016-06.io.spdk:cnode1" -a "$NVMF_FIRST_TARGET_IP" -s "$NVMF_PORT"
41
42 mkdir -p /mnt/device
43
=> 44 devs=`lsblk -l -o NAME | grep nvme`
45
46 for dev in $devs; do
47 timing_enter parted
48 parted -s /dev/$dev mklabel msdos mkpart primary '0%' '100%'
49 timing_exit parted
...
========== Backtrace end ==========
And generated messages in /var/log/messages like:
Apr 18 12:35:50 localhost kernel: nvme nvme0: Connect rejected: status 8 (invalid service ID).
Apr 18 12:35:50 localhost kernel: nvme nvme0: rdma connection establishment failed (-104)
What’s weird is that I could manually run the same steps without a failure.
Ed R
1 year, 11 months
Namespace attribute notification change problem
by Rodriguez, Edwin
We recently updated our repo to the latest master and broke our FC26 autotest systems. I bisected the issue down to this SHA:
[edwinr@ssan-rx2560-01:7]~/p4/SPDK/master/spdk(master)> git show 3165d0c0
commit 3165d0c070a37af45e192cae066f6623612e6bc6
Author: Daniel Verkamp <daniel.verkamp(a)intel.com>
Date: Tue Apr 3 14:32:33 2018 -0700
nvmf: report support for NS Attribute notification
Fixes: 26541489ef92 ("nvmf: implement Get Log Page - Changed NS List")
Fixes: 763ab8888482 ("nvmf: add Namespace attribute notice support")
Change-Id: Id015e4d96fe98a7f6c845821395463e341b7066c
Signed-off-by: Daniel Verkamp <daniel.verkamp(a)intel.com>
Reviewed-on: https://review.gerrithub.io/406247
Tested-by: SPDK Automated Test System <sys_sgsw(a)intel.com>
Reviewed-by: Ben Walker <benjamin.walker(a)intel.com>
Reviewed-by: Jim Harris <james.r.harris(a)intel.com>
diff --git a/lib/nvmf/ctrlr.c b/lib/nvmf/ctrlr.c
index 7981a15e..f8cf4030 100644
--- a/lib/nvmf/ctrlr.c
+++ b/lib/nvmf/ctrlr.c
@@ -1164,6 +1164,7 @@ spdk_nvmf_ctrlr_identify_ctrlr(struct spdk_nvmf_ctrlr *ctrlr, struct spdk_nvme_c
cdata->kas = 10;
cdata->rab = 6;
+ cdata->oaes.ns_attribute_notices = 1;
cdata->ctratt.host_id_exhid_supported = 1;
cdata->aerl = 0;
cdata->frmw.slot1_ro = 1;
I then updated the FC26 machine to the latest available packages, including updating the kernel from 4.15.6-200.fc26.x86_64 to 4.15.17-200.fc26.x86_64 which fixed the problem, however I’m curious why this particular change would have caused a problem.
The error reported was:
09:52:42 # ./app/nvmf_tgt/nvmf_tgt -i 0 -c /x/eng/bbrtp/SPDK-CIT/ssan-rx2560-01/build-20180419093836/spdk/test/nvmf/filesystem/../nvmf.conf
09:52:42 # waitforlisten 31010
09:52:42 # '[' -z 31010 ']'
09:52:42 # rpc_addr=/var/tmp/spdk.sock
09:52:42 # echo 'Waiting for process to start up and listen on UNIX domain socket /var/tmp/spdk.sock...'
Waiting for process to start up and listen on UNIX domain socket /var/tmp/spdk.sock...
09:52:42 # set +x
Starting SPDK v18.04-pre / DPDK 18.02.0 initialization...
[ DPDK EAL parameters: nvmf -c 0xF --file-prefix=spdk0 --base-virtaddr=0x1000000000 --proc-type=auto ]
EAL: Detected 48 lcore(s)
EAL: Auto-detected process type: SECONDARY
EAL: Multi-process socket /var/run/.spdk0_unix_31010_4be0c2c5c82ae6
EAL: Probing VFIO support...
EAL: VFIO support initialized
app.c: 443:spdk_app_start: *NOTICE*: Total cores available: 4
reactor.c: 645:spdk_reactors_init: *NOTICE*: Occupied cpu socket mask is 0x1
reactor.c: 429:_spdk_reactor_run: *NOTICE*: Reactor started on core 1 on socket 0
reactor.c: 429:_spdk_reactor_run: *NOTICE*: Reactor started on core 2 on socket 0
reactor.c: 429:_spdk_reactor_run: *NOTICE*: Reactor started on core 3 on socket 0
reactor.c: 429:_spdk_reactor_run: *NOTICE*: Reactor started on core 0 on socket 0
copy_engine_ioat.c: 318:copy_engine_ioat_init: *NOTICE*: Ioat Copy Engine Offload Enabled
09:52:42 # timing_exit start_nvmf_tgt
09:52:42 # set +x
09:52:42 # python /x/eng/bbrtp/SPDK-CIT/ssan-rx2560-01/build-20180419093836/spdk/scripts/rpc.py construct_malloc_bdev 64 512
09:52:42 # bdevs=' Malloc0'
09:52:42 # python /x/eng/bbrtp/SPDK-CIT/ssan-rx2560-01/build-20180419093836/spdk/scripts/rpc.py construct_malloc_bdev 64 512
09:52:42 # bdevs=' Malloc0 Malloc1'
09:52:42 # modprobe -v nvme-rdma
insmod /lib/modules/4.15.6-200.fc26.x86_64/kernel/drivers/nvme/host/nvme-rdma.ko.xz
09:52:42 # python /x/eng/bbrtp/SPDK-CIT/ssan-rx2560-01/build-20180419093836/spdk/scripts/rpc.py construct_nvmf_subsystem nqn.2016-06.io.spdk:cnode1 'trtype:RDMA traddr:10.63.1.20 trsvcid:4420' '' -a -s SPDK00000000000001 -n ' Malloc0 Malloc1'
09:52:42 # nvme connect -t rdma -n nqn.2016-06.io.spdk:cnode1 -a 10.63.1.20 -s 4420
09:52:43 # mkdir -p /mnt/device
09:52:43 # grep nvme
09:52:43 # lsblk -l -o NAME
09:52:43 # trap - ERR
09:52:43 # print_backtrace
09:52:43 # local shell_options=hxBE
09:52:43 # set +x
========== Backtrace start: ==========
in test/nvmf/filesystem/filesystem.sh:44 -> main()
...
39
40 nvme connect -t rdma -n "nqn.2016-06.io.spdk:cnode1" -a "$NVMF_FIRST_TARGET_IP" -s "$NVMF_PORT"
41
42 mkdir -p /mnt/device
43
=> 44 devs=`lsblk -l -o NAME | grep nvme`
45
46 for dev in $devs; do
47 timing_enter parted
48 parted -s /dev/$dev mklabel msdos mkpart primary '0%' '100%'
49 timing_exit parted
...
========== Backtrace end ==========
And generated messages in /var/log/messages like:
Apr 18 12:35:50 localhost kernel: nvme nvme0: Connect rejected: status 8 (invalid service ID).
Apr 18 12:35:50 localhost kernel: nvme nvme0: rdma connection establishment failed (-104)
What’s weird is that I could manually run the same steps without a failure.
Ed R
1 year, 11 months
Build questions
by Niu, Yawei
Hi, All
Building SPDK with default option will generate lots of static libs, that’s not quite convenient for users to manage the dependent libs for their apps, perhaps few shared libs could be better? Is there any option to generate few integrated shared libs? Another question is that ‘make install’ won’t install the DPDK libs from DPDK submodule along with SPDK libs, I was wondering if it can be improved to install the DPDK libs as well? That’ll be helpful for the users who don’t use external DPDK. Thanks in advance.
Thanks
-Niu
1 year, 11 months
Re: [SPDK] vhost target failover?
by Harris, James R
I agree with Pawel regarding vhost crashes. If the SPDK vhost target crashed, I would recommend treating it similarly to the host kernel crashing. There’s no way to know exactly what may have been inadvertently modified due to the crash.
But the idea of “managed failover” could be useful in terms of upgrading the vhost target. I’m not aware of anyone actively working on this at the moment however.
Regards,
-Jim
From: "Wodkowski, PawelX" <pawelx.wodkowski(a)intel.com>
Date: Monday, April 16, 2018 at 1:47 AM
To: Storage Performance Development Kit <spdk(a)lists.01.org>, James Harris <james.r.harris(a)intel.com>
Subject: RE: Re: [SPDK] vhost target failover?
We can implement any kind of failover mechanism. Starting some kind of proxy process to pass vhost user messages to child process would not be so hard to implement. In theory.
But the question is how to handle crash in the middle of request? In virtio-net situation is much simpler – if TCP network packet is lost it will be retransmitted. If packet is retransmitted after vhost-net target restart - it will be filtered by TCP layer. What to do if in the middle of eg 2MB write vhost crashes and restarts? One solution could be to promote the vhost target restart/recover to the SCSI reset event. It's doable.
Another issue is that if vhost crashes it mean there was some serious issue including possibility of trashing guest memory. Personally, I recommend (and I think DPDK recommend this also) to save what you can and restart everything.
Adding Jim as he could write something more here.
Pawel
From: SPDK [mailto:spdk-bounces@lists.01.org] On Behalf Of Huang Frank
Sent: Monday, April 16, 2018 10:09 AM
To: spdk <spdk(a)lists.01.org>
Subject: Re: [SPDK] vhost target failover?
hi, Pawel
Thanks.
Is there any suggestions for this issue? Or any plans to provide High Availability of vhost target in the future?
________________________________
kinzent(a)hotmail.com<mailto:kinzent@hotmail.com>
From: Wodkowski, PawelX<mailto:pawelx.wodkowski@intel.com>
Date: 2018-04-16 16:02
To: Storage Performance Development Kit<mailto:spdk@lists.01.org>
Subject: Re: [SPDK] vhost target failover?
There is none currently. Device will be seen as dead. All requests will stuck. Anything else related to guest should be unaffected.
Pawel
From: SPDK [mailto:spdk-bounces@lists.01.org] On Behalf Of Huang Frank
Sent: Monday, April 16, 2018 9:42 AM
To: spdk <spdk(a)lists.01.org<mailto:spdk@lists.01.org>>
Subject: [SPDK] vhost target failover?
Hi，all
What's the failover mechism of vhost target? If the vhost target goes to crash, how to make sure the guest can process without affectting?
Thanks,
Frank.
________________________________
kinzent(a)hotmail.com<mailto:kinzent@hotmail.com>
1 year, 11 months
