On 9/19/2018 11:39 PM, hch@lst.de wrote:

On Tue, Sep 18, 2018@12:43:30PM -0700, James Smart wrote:

quoted

The issue that I believe exists is that the multipath driver/core knows how
to retry on a different path when the request is accepted then the
nvme_complete_rq() is called. But it doesn't know how to retry on a
different path when the initial transport:queue_rq() fails - the io ends up
failing completely.?? I think we need to fix that code path, not "busy"
requeue the mpath io.

The multipath code handles failures from nvme_complete_rq just fine,
in fact even with this patch we still don't accept the command into
queue_rq.  It is just that BLK_STS_RESOURCE is a magic indicator
for the blk-mq core to retry internally and not hand it back to the
next higher level (which would be the multipath code, either nvme
or dm for that matter).

your response is a bit cryptic

I agree with you - that nvme_complete_rq() handles it fine. But in the 
path where the transport->queue_rq() is called, and the io is bounced 
due to controller state checks, nvme_complete_rq() isn't being called.? 
If queue_rq() return BLK_STS_RESOURCE, its ok as the io gets requeued in 
blk-mq, but it could sit there for 60s or so. But if queue_rq() see the 
io marked NVME_MPATH, it returns BLK_STS_IOERR? 
(blk_mq_complete_request() isn't called), and the blk-mq layer ends up 
calling blk_mq_end_request().

-- james