On Mon, Feb 17, 2014 at 10:36:20AM +0100, Bart Van Assche wrote: > This comment makes a lot of sense to me. The approach that has been > taken in the scsi-mq patches that have been posted on February 5 is to > associate one blk-mq device with each LUN. That blk-mq device has one > hctx with queue depth shost->cmd_per_lun. So if there are multiple LUNs > per SCSI host the combined hctx queue depth of its LUNs can exceed > shost->can_queue. I'm not sure whether it's possible to prevent this > without modifying the block layer. How about modifying the block layer > such that a single hctx can be shared by multiple block devices and > adding cmd_per_lun support in the block layer ? I think that would allow > to prevent having to bounce submission in the SCSI mid-layer. Most of the scsi multiqueue work so far has been about modifying the block layer, so I'm defintively now shy about doing that were needed. And I think we will eventually need to be able to have n:m queue to hctx mapping instead of the current 1:n one. I think the biggest issue will be to sort out the tag allocation. I'm going to look into this whole cluster of issues once the basic functionality is fully working. -- 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
