NVMeoF: multipath stuck after bringing one ethernet port down

[Christoph Hellwig]

On Mon, Jun 05, 2017 at 11:53:58AM +0300, Sagi Grimberg wrote:
>> So this looks somewhat bogus to me, while the rest looks ok.
>
> The point here is that RECONNECTING is a ctrl state that has a
> potential to linger for a long time (unlike RESETTING or DELETING),
> so we don't want to trigger requeue right away.
>
> I'm open to other ideas. I just want to prevent triggering a redundant
> loop of queue_rq -> fail with BUSY -> queue_rq -> fail with BUSY ...
>
> Thoughts?

Let's get this patch in, then sort out a common stratefy for the
dev_loss_tmo for all drivers, as FC is already doing some work in
that area.