Re: [RFC PATCH 0/9] vhost-nvme: new qemu nvme backend using nvme target
From: Paolo Bonzini <pbonzini@redhat.com>
Date: 2015-12-01 16:02:19
Also in:
linux-nvme, qemu-devel
Possibly related (same subject, not in this thread)
- 2015-11-21 · Re: [RFC PATCH 0/9] vhost-nvme: new qemu nvme backend using nvme target · Paolo Bonzini <pbonzini@redhat.com>
- 2015-11-20 · [RFC PATCH 0/9] vhost-nvme: new qemu nvme backend using nvme target · mlin@kernel.org (Ming Lin)
- 2015-11-20 · Re: [RFC PATCH 0/9] vhost-nvme: new qemu nvme backend using nvme target · Christoph Hellwig <hch@lst.de>
- 2015-11-20 · [RFC PATCH 0/9] vhost-nvme: new qemu nvme backend using nvme target · mlin@kernel.org (Ming Lin)
On 01/12/2015 00:20, Ming Lin wrote:
qemu-nvme: 148MB/s vhost-nvme + google-ext: 230MB/s qemu-nvme + google-ext + eventfd: 294MB/s virtio-scsi: 296MB/s virtio-blk: 344MB/s "vhost-nvme + google-ext" didn't get good enough performance.
I'd expect it to be on par of qemu-nvme with ioeventfd but the question is: why should it be better? For vhost-net, the answer is that more zerocopy can be done if you put the data path in the kernel. But qemu-nvme is already using io_submit for the data path, perhaps there's not much to gain from vhost-nvme... Paolo
Still tuning.