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

[Randy Jennings]

I think Nilay has done some great work with the latency scheduler, and
we have it in our queue for evaluation.  But we have not done so yet,
so I would appreciate if queue-depth would continue to be available
until the latency scheduler has been more fully established as the
prime choice.

As to round-robin, I agree it would be great to see it disappear from
all of our customers installations, but I have found it useful in
evaluating multipath failover behavior because it is easier to reason
about and construct the test cases.  So, I would appreciate if it
would remain for debugging only.  I would certainly be open to a
mechanism that made it a little bit hard to set round-robin as the
queue policy, though.

Sincerely,
Randy Jennings

On Mon, Sep 7, 2026 at 7:31 AM Hannes Reinecke <hare at suse.de> wrote:
>
> 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