On 02/17/14 23:00, Christoph Hellwig wrote: > Most of the scsi multiqueue work so far has been about modifying the > block layer, so I'm definitively 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 it would be great if the blk-mq core would support an n:m queue to hctx mapping. One of the advantages of that approach would be that the blk-mq layer already keeps track of how many commands are queued per hctx and hence that would allow to eliminate the host_busy counter from the SCSI mid-layer. However, this involves a change in semantics. I hope it's fine to change the semantics of the hosts->can_queue parameter from "maximum number of commands queued per SCSI host" into "maximum number of commands queued per hctx" ? Bart. -- 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
