On Fri, 2016-04-08 at 13:29 +0200, Hannes Reinecke wrote: > Hi all, > > I'd like to propose a topic on block-mq issues with FC. > During my performance testing using block/scsi-mq with FC I've hit > several issues I'd like to discuss: > > - timeout handling: > Out of necessity the status of any timed out command is undefined. > So to be absolutely safe HBAs will be using extended timeouts here > (eg 70secs for lpfc). During that time we _could_ signal I/O timeout > to the upper layers, but then the tag will be reused, despite the > HBA still having a reference to it. > I'd like to discuss how this could be solved best with blk-mq. What's wrong with the obvious answer: the tag shouldn't be re-used until after at least the TMF abort. If we need to escalate that then it looks like the controller lost the tag and requires a bigger hammer. However, when I look at what we do, it seems the running abort handler is triggered from the block timeout function, so where's the problem? ... surely mq can't free the tag until that returns, because it might extend the time. James > - Adaption on other HBAs to multiqueue: > The current block-mq design assumes symmetric send and receive > queues (in effect queue pairs). Any hardware _not_ providing this > (like qla2xxx) can not be easily converted to scsi-mq. I'd like to > discuss how one could approach converting these drivers. > > Cheers, > > Hannes -- 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
