- To: Paolo Bonzini <pbonzini@xxxxxxxxxx>
- Subject: Re: [PATCH 0/6] tcm_vhost/virtio-scsi WIP code for-3.6
- From: "Michael S. Tsirkin" <mst@xxxxxxxxxx>
- Date: Thu, 5 Jul 2012 20:26:57 +0300
- Cc: Anthony Liguori <aliguori@xxxxxxxxxx>, "Nicholas A. Bellinger" <nab@xxxxxxxxxxxxxxx>, target-devel <target-devel@xxxxxxxxxxxxxxx>, linux-scsi <linux-scsi@xxxxxxxxxxxxxxx>, lf-virt <virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx>, kvm-devel <kvm@xxxxxxxxxxxxxxx>, Stefan Hajnoczi <stefanha@xxxxxxxxxxxxxxxxxx>, Zhi Yong Wu <wuzhy@xxxxxxxxxx>, Anthony Liguori <aliguori@xxxxxxxxxxxxxxxxxx>, Christoph Hellwig <hch@xxxxxx>, Jens Axboe <axboe@xxxxxxxxx>, Hannes Reinecke <hare@xxxxxxx>
- In-reply-to: <4FF5A90F.5050902@redhat.com>
On Thu, Jul 05, 2012 at 04:47:43PM +0200, Paolo Bonzini wrote:
> 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. :)
Anyway, all I was saying is new technology often lacks some features of
the old one. We are not forcing new inferior one on anyone, so we can
let it mature it tree.
> >> 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 linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
[SCSI Target Devel]
[Linux SCSI Target Infrastructure]
[Kernel Newbies]
[Share Photos]
[IDE]
[Security]
[Git]
[Netfilter]
[Bugtraq]
[Photos]
[Yosemite]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Linux ATA RAID]
[Linux IIO]
[Samba]
[Video 4 Linux]
[Device Mapper]
[Linux Resources]