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

Randy Jennings randyj at purestorage.com
Mon Sep 14 11:56:08 PDT 2026


> Randy, would it be possible for you folks to evaluate it as well? I will ask
> some folks on our side as well. I'm concerned that Nilay is the only one who
> has evaluated it in his lab.
Yes, absolutely, but there is going to be a time delay due to wrapping up
some current priorities.  I'd say we'd get to it in more than 2 months but
less than 6.  That is the best promise I can give right now.  (Yes, it is
behind some work for stretched subsystems and CCR/CQT, which are
higher priorities for me.)

> Overall, I am perfectly fine with the approach this path selector is
> taking, but I worry
> that we are growing path-selectors that are slightly different in subtle
> ways...
Agreed.

> TBH, I still don't understand what use-cases this path selector is more
> appropriate than queue-depth, or vice-versa.
I had this question, too, and we talked about it in Zagreb.  My
understanding from that discussion is that latency can handle
full queues better than queue-depth.  When you have shallow
queues, you still get information to make a path decision on.

Sincerely,
Randy Jennings



More information about the Linux-nvme mailing list