Re: [PATCH V3 0/8] nvme: Refactor and expose per-controller timeout configuration

["Maurizio Lombardi" <mlombard@arkamax.eu>]

On Mon Apr 13, 2026 at 10:12 AM CEST, Hannes Reinecke wrote:
> On 4/10/26 09:39, Maurizio Lombardi wrote:
>> This patchset tries to address some limitations in how the NVMe driver handles
>> command timeouts.
>> Currently, the driver relies heavily on global module parameters
>> (NVME_IO_TIMEOUT and NVME_ADMIN_TIMEOUT), making it difficult for users to
>> tune timeouts for specific controllers that may have very different
>> characteristics. Also, in some cases, manual changes to sysfs timeout values
>> are ignored by the driver logic.
>> 
>> For example this patchset removes the unconditional timeout assignment in
>> nvme_init_request. This allows the block layer to correctly apply the request
>> queue's timeout settings, ensuring that user-initiated changes via sysfs
>> are actually respected for all requests.
>> 
>> It introduces new sysfs attributes (admin_timeout and io_timeout) to the NVMe
>> controller. This allows users to configure distinct timeout requirements for
>> different controllers rather than relying on global module parameters.
>> 
> What about KATO?
> With this patchset the user can set arbitrary values to the I/O timeout,
> which easily can be lower than KATO.

it's worth noting that unless I am missing something the user can already
trigger this exact scenario today by setting an I/O timeout lower than KATO,
using the global nvme_io_timeout module parameter. 

> And as per spec a KATO timeout implies a transport disruption, requiring
> a controller reset.
> But due to the internal design of the nvme error handling we do conflate
> transport disruption and command timeout, so an _I/O_ timeout triggers
> a controller reset.

this is true only for TCP and RDMA host drivers,
because PCI and FC already support I/O aborts.

Apple doesn't support abort, but it's not clear in the comments if it's
the driver that lacks support for it or it's the controller that
doesn't handle the abort command.

> Which means that a command timeout lower than KATO will result in false
> positives, with the controller being reset even though the connection
> is perfectly happy.

Right.

We could try to send abort commands in RDMA and TCP host drivers timeout handlers.
Maybe cancel, if supported, and falling back to abort if cancel
commands are not available. I already had patches for this kind of
stuff.

Maurizio