Announcement: SPDK Jenkins CI Downtime
by Latecki, Karol
Hi everyone,
I'd like to inform that Jenkins CI for SPDK will be offline for the weekend.
When?
Oct 19th 2:00 PM UTC - Oct 22nd 10:00 AM UTC
Why?
Planned electrical maintenance. Server room will be completely powered down.
Any commits pushed to spdk/spdk Gerrithub during weekend will have tests run first thing in the morning on Oct 22nd.
Thanks,
Karol
--------------------------------------------------------------------
Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN.
Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek
przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by
others is strictly prohibited.
3 years, 7 months
flush request error
by wanghonghui
hi all:
I ran a kvm virtual machine(Linux), and this machine have a vhost spdk disk
when I use mkfs.ext4 to create a filesystem on this disk, I got a error "blk_update_request: I/O error , dev vdb, sector 0"
I test three kernel version :
4.0, 4.1(from upstream compiled by myself)
3.10.0-693(from centos7)
only 4.0 and 4.1 have this problem, 3.10.0-693 is ok
The reason is mkfs.ext4 issue some flush requests to vhost spdk disk, but spdk's process_blk_request function do not issue the VIRTIO_BLK_T_FLUSH requests to bdev
so I modify the process_blk_request function and the problem resolved:
diff --git a/lib/vhost/vhost_blk.c b/lib/vhost/vhost_blk.c
index 9e986d4..ee3c8a8 100644
--- a/lib/vhost/vhost_blk.c
+++ b/lib/vhost/vhost_blk.c
@@ -269,6 +269,14 @@ process_blk_request(struct spdk_vhost_blk_task *task, struct spdk_vhost_blk_dev
task->used_len, ' ');
blk_request_finish(true, task);
break;
+ case VIRTIO_BLK_T_FLUSH:
+ task->used_len = payload_len + sizeof(*task->status);
+ rc = spdk_bdev_flush(bvdev->bdev_desc, bvdev->bdev_io_channel, 0, 0, blk_request_complete_cb, task);
+ if (rc) {
+ invalid_blk_request(task, VIRTIO_BLK_S_IOERR);
+ return -1;
+ }
+ break;
3 years, 7 months
dpdk new memory model
by Shahar Salzman
Hi,
Looking at dpdkenv, I read that " SPDK holds off with using the new memory management model just yet".
Is there something specific you are waiting for? Do you know of unsolved issues? What do you think are the risks of using the new memory management?
Shahar
3 years, 7 months
Re: [SPDK] Strict aliasing errors building on CentOS6
by Harris, James R
On 10/14/18, 2:38 AM, "SPDK on behalf of Shahar Salzman" <spdk-bounces(a)lists.01.org on behalf of shahar.salzman(a)kaminario.com> wrote:
Hi,
Upgrading to dpdk 18.05+, I have "strict aliasing" errors again.
Added the following patch to dpdkbuild to use -fno-strict-aliasing for redhat/centos 6.
https://review.gerrithub.io/c/spdk/spdk/+/429356
Hi Shahar,
The issue you’ve observed is more of an issue with an unsupported compiler version, not the Linux distribution. I think I would prefer something like https://review.gerrithub.io/#/c/spdk/spdk/+/429489/. Then you could build SPDK using:
make EXTRA_DPDK_CFLAGS=”-fno-strict-aliasing”
This also makes it clearer that SPDK does not explicitly support building DPDK with the older compiler version – since the user has to take extra steps to get it to work.
-Jim
3 years, 7 months
Patches for upcoming 18.10 release
by Harris, James R
Hi,
Ben Walker and I have made an initial pass through the open patches on GerritHub. Critical patches for the upcoming v18.10 release have been marked with an “18.10” hashtag. Please focus on updates, reviews and testing for these patches.
If you have a patch that is not marked with an “18.10” hashtag but you feel is critical, please respond with associated GerritHub URLs to this e-mail.
Patches without an “18.10” hashtag may still be merged next week provided they are low risk. Other patches will be deferred until after the v18.10 release at the end of this month.
Thanks,
Jim Harris
3 years, 7 months
"Copy failed" errors with SPDK IOAT sample; SPDK IOAT performance
by Rami Rosen
Hello, sdpk-dev,
I have a question about IOAT SPDK example.
When I am running the IOAT example (examples/ioat/verify) on Skylake host
without any code changes for a single second, I get "copy failed" errors,
over several tries. Also when I am running it for a full hour, there are no
"copy failed" errors.
For example:
...
Queue depth: 32
lcore = 0, copy success = 9132, copy failed = 0, fill success = 9132, fill
failed = 0
lcore = 1, copy success = 9435, copy failed = 0, fill success = 9435, fill
failed = 0
lcore = 2, copy success = 9128, copy failed = 0, fill success = 9129, fill
failed = 0
lcore = 3, copy success = 9259, copy failed = 0, fill success = 9259, fill
failed = 0
...
When I am trying to set a fixed size of 512 for the buffer and run the test
for a
single second, I **consistently** get several errors of "copy failed", and
this
occurs consistently.
The only change I did in the code is setting the ioat->len to be of a fixed
size of 512, as follows:
diff --git a/examples/ioat/verify/verify.c b/examples/ioat/verify/verify.c
index c344ba82..10628f51 100644
--- a/examples/ioat/verify/verify.c
+++ b/examples/ioat/verify/verify.c
@@ -152,7 +152,9 @@ static void prepare_ioat_task(struct thread_entry
*thread_entry, struct ioat_tas
ioat_task->src = (void *)((uintptr_t)g_src + src_offset);
ioat_task->dst = (void *)((uintptr_t)ioat_task->buffer +
dst_offset);
}
- ioat_task->len = len;
+ /* Test: use fixed len of 512 */
+ //ioat_task->len = len;
+ ioat_task->len = 512;
ioat_task->thread_entry = thread_entry;
For example:
...
lcore = 0, copy success = 13865, copy failed = 7, fill success = 13873,
fill failed = 0
lcore = 1, copy success = 14336, copy failed = 9, fill success = 14346,
fill failed = 0
lcore = 2, copy success = 14564, copy failed = 11, fill success = 14576,
fill failed = 0
lcore = 3, copy success = 14556, copy failed = 11, fill success = 14568,
fill failed = 0
...
Have you ever encountered such an issue ?
Any ideas what can be the reason for it ?
Running for an hour the IOAT example without any code changes again gives
no errors:
Run time: 3600 seconds
Core mask: 0xf
Queue depth: 32
lcore = 0, copy success = 32604920, copy failed = 0, fill success =
32604920, fill failed = 0
lcore = 1, copy success = 33510362, copy failed = 0, fill success =
33510362, fill failed = 0
lcore = 2, copy success = 33471071, copy failed = 0, fill success =
33471071, fill failed = 0
lcore = 3, copy success = 33443397, copy failed = 0, fill success =
33443397, fill failed = 0
Another question is: unless I miss something, it seems that the amount of
packets per second are very low when running the original IOAT example code
(no code changes); it is about 13,000 copies per core + 13,000 fill copies.
This is way less than when running a simple userspace app with memcpy which
does something parallel. Is there any benefits for using SPDK IOAT with
this performance ? Is this expected ? What is the use case
for using SPDK with such performance ?
Regards,
Rami Rosen
3 years, 7 months
Re: [SPDK] Multiple start/stop of reactor and add/remove of bdev
by Harris, James R
Hi Shahar,
Can you describe why you require starting/stopping the reactor on demand?
Thanks,
-Jim
On 10/8/18, 1:07 AM, "SPDK on behalf of Shahar Salzman" <spdk-bounces(a)lists.01.org on behalf of shahar.salzman(a)kaminario.com> wrote:
Hi,
I am now working with my passthrough bdev directly from my application, and require adding/removing them dynamically. In addition, I also require starting/stopping the reactor on demand without tearing down the entire system (e.g. dpdk stays initialized). This mostly works out of the box, but there are a few globals and bdev internal fields which require re-init or tear down.
In addition, the copy engine did not io_unregister itself, so I also added this in the patchset, allowing me the following application life span:
- env init (init config, spdk_env_init)
- reactors init
- while (application is alive)
subsystem_init + reactor start
...
Do some NVMeF stuff
...
subsysem_fini + reactors stop
- reactors_fini
- rpc_finish
I submitted the following patches for review:
https://review.gerrithub.io/c/spdk/spdk/+/428305
https://review.gerrithub.io/c/spdk/spdk/+/428304
https://review.gerrithub.io/c/spdk/spdk/+/428303
https://review.gerrithub.io/c/spdk/spdk/+/428302
WDYT?
Shahar
_______________________________________________
SPDK mailing list
SPDK(a)lists.01.org
https://lists.01.org/mailman/listinfo/spdk
3 years, 7 months
