On Thu, 2012-07-05 at 16:53 +0300, Michael S. Tsirkin wrote: > On Thu, Jul 05, 2012 at 12:22:33PM +0200, Paolo Bonzini wrote: > > Il 05/07/2012 03:52, Nicholas A. Bellinger ha scritto: > > > > > > fio randrw workload | virtio-scsi-raw | virtio-scsi+tcm_vhost | bare-metal raw block > > > ------------------------------------------------------------------------------------ > > > 25 Write / 75 Read | ~15K | ~45K | ~70K > > > 75 Write / 25 Read | ~20K | ~55K | ~60K > > > > This is impressive, but I think it's still not enough to justify the > > inclusion of tcm_vhost. In my opinion, vhost-blk/vhost-scsi are mostly > > worthwhile as drivers for improvements to QEMU performance. We want to > > add more fast paths to QEMU that let us move SCSI and virtio processing > > to separate threads, we have proof of concepts that this can be done, > > and we can use vhost-blk/vhost-scsi to find bottlenecks more effectively. > > A general rant below: > > OTOH if it works, and adds value, we really should consider including code. > To me, it does not make sense to reject code just because in theory > someone could write even better code. Code walks. Time to marker matters too. > Yes I realize more options increases support. But downstreams can make > their own decisions on whether to support some configurations: > add a configure option to disable it and that's enough. > +1 for mst here. I think that type of sentiment deserves a toast at KS/LC in August. ;) > > In fact, virtio-scsi-qemu and virtio-scsi-vhost are effectively two > > completely different devices that happen to speak the same SCSI > > transport. Not only virtio-scsi-vhost must be configured outside QEMU > > configuration outside QEMU is OK I think - real users use > management anyway. But maybe we can have helper scripts > like we have for tun? > > > and doesn't support -device; > > This needs to be fixed I think. > > > it (obviously) presents different > > inquiry/vpd/mode data than virtio-scsi-qemu, > > Why is this obvious and can't be fixed? Userspace virtio-scsi > is pretty flexible - can't it supply matching inquiry/vpd/mode data > so that switching is transparent to the guest? > So I imagine that setting inquiry/vpd/mode via configfs attribs to match whatever the guest wants to see (or expects to see) can be enabled via /sys/kernel/config/target/core/$HBA/$DEV/[wwn,attrib]/ easily to whatever is required. However, beyond basic SCSI WWN related bits, I would avoid trying to match complex SCSI target state between the in-kernel patch and QEMU SCSI. We've had this topic come up numerous times over the nears for other fabric modules (namely iscsi-target) and usually it end's up with a long email thread re-hashing history of failures until Linus starts yelling at the person who is pushing complex kernel <-> user split. The part where I start to get nervous is where you get into the cluster + multipath features. We have methods in TCM core that rebuild the exact state of this bits based upon external file metadata, based upon the running configfs layout. This is used by physical node failover + re-takeover to ensure the SCSI client sees exactly the same SCSI state. Trying to propagate up this type of complexity is where I think you go overboard. KISS and let's let fabric independent configfs (leaning on vfs) do the hard work for tracking these types of SCSI relationships. > > so that it is not possible to migrate one to the other. > > Migration between different backend types does not seem all that useful. > The general rule is you need identical flags on both sides to allow > migration, and it is not clear how valuable it is to relax this > somewhat. > I really need to learn more about how QEMU Live migration works wrt to storage before saying how this may (or may not) work. We certainly have no problems doing physical machine failover with target_core_mod for iscsi-target, and ATM I don't see why the QEMU userspace process driving the real-time configfs configuration of the storage fabric would not work.. > > I don't think vhost-scsi is particularly useful for virtualization, > > honestly. However, if it is useful for development, testing or > > benchmarking of lio itself (does this make any sense? :)) that could be > > by itself a good reason to include it. > > > > Paolo > _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
