[PATCH 1/2] nvme: multipath: round-robin: fix logic for non-optimized paths

[Hannes Reinecke]

On 7/21/20 7:19 PM, Sagi Grimberg wrote:
> 
>>>> Handle the special case where we have exactly one optimized path,
>>>> which we should keep using in this case. Also, use the next
>>>> non-optimized path, not the last one.
>>>
>>> Not sure I understand, does this patch also use nonopt paths if we
>>> have a single opt path?
>>
>> Indeed, the latter change should be removed from this patch.
> 
> Why should we even do this? we have a clear indication from the
> controller on ns access. If we have a optimized path we should never
> select any non-optimized path.
> 
> What if a non-optimized path has a 50x higher access latency? it's just
> wrong to use this path...

Errm. I think Martin didn't state clearly what the problem was.

The problem is when the _current_ path is the only optimized path, and 
all other paths are non-optimized:

	for (ns = nvme_next_ns(head, old);
	     ns != old;
	     ns = nvme_next_ns(head, ns)) {

We start with the _next_ path, and stop _before_ we check the 'old' 
path. Consequently the 'old' path is never checked, and never selected.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke            Teamlead Storage & Networking
hare at suse.de                               +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer