[PATCH 4/6] nvme-mpath: support controller crd when failing over request

[Sagi Grimberg]

On 02/09/2026 16:43, Christoph Hellwig wrote:
> On Sun, Aug 23, 2026 at 11:49:00AM +0300, Sagi Grimberg wrote:
>> When failing over a request (due to a path based status) we should
>> repect controller crd returned in the nvme completion as much as
>> possible. Hence we want to delay the failover command execution by
>> the controller crdt.
>>
>> We allocate a new nvme_mpath_failover_timer referencing the request
>> stolen bios in a staging list, and when the command retry delay expires,
>> and only then the bios are moved to the mpath head requeue list which is
>> immediately kicked to re-submit these bios. If we failed to allocate
>> a fot, we fallback to the existing behavior.
>>
>> Given that we now have a new staging list for mpath devices, we drain
>> them when removing the device.
> Given that we only have a few potential CRD levels, what about having
> the "container" for the requing statically preallocated for each?

I am not sure I understand how we can do that. While there are 3 crd levels,
requests can fail at any point in time with a given crd level, I don't 
see how we can
reliably requeue after the crd level has elapsed without getting into 
the situation
before (if any command failed with crd level X, it would extend the 
timer while other
commands are pending on it).

The allocation in the failover path is not ideal, however the fallback 
gets us to the normal
failover which we have today. And failovers are fairly rare, so I don't 
know if it is worth optimizing for...