[PATCH v8 00/10] nvme-multipath: introduce latency I/O policy

[Hannes Reinecke]

On 8/31/26 8:31 AM, Nilay Shroff wrote:
> On 8/31/26 3:23 AM, Sagi Grimberg wrote:
>>
>>
[ .. ]>> I would like to avoid introducing this as a config knob if it is
>> always behaves better.
>>
>> What do others think?
> 
> Good point, however my view is that we may not want to immediately 
> deprecate or remove queue-depth/round-robin. Based on my testing so
 > far, across a variety of workloads, including intermittent packet
 > loss, the latency policy has performed better than queue-depth and
 > round-robin. However, I would like to see it evaluated against a
 > broader set of workloads and scenarios, including cases that I > may 
not have considered/known.
> 
> Once we have broader evidence and establish that latency consistently 
> performs at least as well as queue-depth/round-robin without any
 > significant downside, then I think it would be reasonable to consider
 > deprecating those policies and  keeping only numa|latency.>
> Until then, I would prefer to keep queue-depth and round-robin as 
> baseline policies against which we can compare the latency policy.
> 
> But let's wait and see what others think.
> 
I think that we can deprecate round-robin now that we have
queue-depth and latency.
But I also think that we need both, queue-depth _and_ latency as both
latch on different properties, and there are use-cases where one might
have workloads which prefer one or the other.

Having a config option to select the default (and possibly disable some
I/O schedulers) would be completely fine with me, too.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                  Kernel Storage Architect
hare at suse.de                                +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich