Measure the performance overhead imposed by Rust

[xxks-kkk]

NOTE: working branch; not ready to merge

[xxks-kkk]

Sequential write throughput using SPDK + rust: 886580086.580086589 MB/s for write 1GB Sequential write throughput using dd: 776 MB/s

dd command: dd if=/dev/zero of=/mnt/ssd/zeyuan/testfile bs=1G count=1 oflag=dsync

@vijay03

[xxks-kkk]

Even with writing random strings, SPDK seems amazingly fast throughput: 259109311.740890712 MB/s

@vijay03

[xxks-kkk]

Things to try next:

1. Modify C program in hello_nvme_bdev to measure the sequential write performance using the C program from SPDK and compare

2. Verify that the sequential write using SPDK + rust has actually been written to the disk after async! call

• check this inside Rust + SPDK
• also check the write complete using some C program or dd (not sure how)

[xxks-kkk]

Now, we discover a bug

<-- snip -->
[2019-01-11T03:44:57Z DEBUG spdk_rs::bdev] nbytes: 1073741824
bdev_nvme.c:1526:bdev_nvme_queue_cmd: *ERROR*: writev failed: rc = -22
Successfully write to bdev
[2019-01-11T03:44:57Z DEBUG benchmarks::language] Time elapsed in write 1073741824 bytes is: 306.115µs
[2019-01-11T03:44:57Z DEBUG benchmarks::language] throughput: 3507641977688.124 byte/s
throughput: 3345148.065269588 MB/s
Successful
Successfully shutdown SPDK framework

As one can see the write doesn't happen successfully. We need to investigate this and very likely, this is the root cause why we get the amazingly fast number.

bdev_nvme.c:1526:bdev_nvme_queue_cmd: *ERROR*: writev failed: rc = -22

[xxks-kkk]

TODO:

1. Verify the correctness of fill_fixed by implementing the test case
2. Make sure all the spdk_rs::bdev::write calls are successful

[xxks-kkk]

TODO:

Merge the test code of fill_fixed from branch https://github.com/utsaslab/rustfs/tree/overhead-benchmark-build-break

[xxks-kkk]

The root cause for the bug is there is no null terminator for *mut c_void buffer and thus, we call as_str() in read(), rust doesn't know where the string end. This is tricky as I need to know where to append null terminator without making data inconsistent

[xxks-kkk]

TODO: we need to implement a knob to switch between Malloc0 and Nvme0n1 so that we can have a smooth switch between physical host and QEMU development environment.