Hi KS-PCs, I'd like to propose a SCSI performance mini-summit to see how interested folks are in helping address the long-term issues that SCSI core is currently facing wrt to multi-lun per host and heavy small block random I/O workloads. I know this would probably be better suited for LSF (for the record it was proposed this year) but now that we've acknowledge there is a problem with SCSI LLDs vs. raw block drivers vs. other SCSI subsystems, it would be useful to get the storage folks into a single room at some point during KS/LPC to figure out what is actually going on with SCSI core. As mentioned in the recent tcm_vhost thread, there are a number of cases where drivers/target/ code can demonstrate this limitation pretty vividly now. This includes the following scenarios using raw block flash export with target_core_mod + target_core_iblock export and the same small block (4k) mixed random I/O workload with fio: *) tcm_loop local SCSI LLD performance is an order of magnitude slower than the same local raw block flash backend. *) tcm_qla2xxx performs better using MSFT Server hosts than Linux v3.x based hosts using 2x socket Nehalem hardware w/ PCI-e Gen2 HBAs *) ib_srpt performs better using MSFT Server host than RHEL 6.x .32 based hosts using 2x socket Romley hardware w/ PCI-e Gen3 HCAs *) Raw block IBLOCK export into KVM guest v3.5-rc w/ virtio-scsi is behind in performance vs. raw local block flash. (cmwq on the host is helping here, but still need to with MSFT SCSI mini-port) Also, with 1M IOPs into a single VM guest now being done by other non Linux based hypervisors, the virtualization bit for high performance KVM SCSI based storage is quickly coming on.. So all of that said, I'd like to at least have a discussion with the key SCSI + block folks who will be present in San Diego on path forward to address these without having to wait until LSF-2013 + hope for a topic slot to materialize then. Thank you for your consideration, --nab -- 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
