[PATCH] nvme: remove multipath module parameter

[John Meneghini]

On 3/9/25 1:23 PM, Nilay Shroff wrote:
>> It honestly has potential to solve some real problems, like
>> re-enumeration triggered by a link reset on an in-use drive. You'd
>> currently need to close the old handle and open a new on, even though
>> it's the same device. It may not even be possible to do that if that
>> device contains your root partition, and then you can only power cycle.
>>
>> The downside is we wouldn't get the short cut to blk_mq_submit_bio. We'd
>> instead stack that atop an indirect call, so it's not free.
>>
> Yes agreed however it seems advantages of using an indirect call outweighs
> using the short cut to blk_mq_submit_bio. Moreover it seems the cost of
> indirect call is trivial because we already cache the nexthop.
> 
> I integrated your proposed patch (with few trivial additional changes on top)
> and I see that it's coming out nicely. I ran few tests and confirmed it's
> working well. However, in the proposed patch we*always* delay (~10 sec) the
Have you tested this with a NVMe-oF controller... yet?

Where did the number 10 seconds come from?

> removal of multipath head node. That means that even while removing the
> nvme module (rmmod nvme) or if user delete/detache the namespace, we delay
> the removal of head node but that may not be what we want. So I'd suggest
> instead, delayed removal of multipath head not shall be configurable using a
> sysfs attribute. With this attribute then we shall let user opt for pinning
> the head node (with optional delayed time as well?). And it's only when user

So be aware the TP-4129 is adding a CQT parameter which does almost exactly this.

> shows the intent to pin the node we should delay its removal. This is what
> exactly (pinning of head node) Christoph's proposed patch implements. So I'd
> suggest a bit of amalgamation of yours as well as Christoph patch to implement
> this change.

Please cc: me on your patches Nilay, I'd like to test them with my NVMe-oF testbed.

/John