Il 05/07/2012 16:40, Michael S. Tsirkin ha scritto: >> virtio-scsi is brand new. It's not as if we've had any significant >> time to make virtio-scsi-qemu faster. In fact, tcm_vhost existed >> before virtio-scsi-qemu did if I understand correctly. Yes. > Can't same can be said about virtio scsi - it seems to be > slower so we force a bad choice between blk and scsi at the user? virtio-scsi supports multiple devices per PCI slot (or even function), can talk to tapes, has better passthrough support for disks, and does a bunch of other things that virtio-blk by design doesn't do. This applies to both tcm_vhost and virtio-scsi-qemu. So far, all that virtio-scsi vs. virtio-blk benchmarks say is that more benchmarking is needed. Some people see it faster, some people see it slower. In some sense, it's consistent with the expectation that the two should roughly be the same. :) >> But guest/user facing decisions cannot be easily unmade and making >> the wrong technical choices because of premature concerns of "time >> to market" just result in a long term mess. >> >> There is no technical reason why tcm_vhost is going to be faster >> than doing it in userspace. > > But doing what in userspace exactly? Processing virtqueues in separate threads, switching the block and SCSI layer to fine-grained locking, adding some more fast paths. >> Basically, the issue is that the kernel has more complete SCSI >> emulation that QEMU does right now. >> >> There are lots of ways to try to solve this--like try to reuse the >> kernel code in userspace or just improving the userspace code. If >> we were able to make the two paths identical, then I strongly >> suspect there'd be no point in having tcm_vhost anyway. > > However, a question we should ask ourselves is whether this will happen > in practice, and when. It's already happening, but it takes a substantial amount of preparatory work before you can actually see results. Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
