[PATCH 2/2] nvme-multipath: round-robin I/O policy

[hch@lst.de (Christoph Hellwig)]

On Tue, Nov 20, 2018@09:30:32PM +0100, Hannes Reinecke wrote:
>> So you never consider non-optimized paths here?
>>
> Yes, correct. Two reasons:
> - We try to optimize for performance. Selecting a non-optimized path per 
> definition doesn't provide that.
> - The selection algorithm becomes overly complex, and will require an even 
> more complex mechanism to figure out at which point the use of a 
> non-optimized path become feasible.

We can still have a system where we don't see any optimized path at all,
so you will need some kind of fallback.

>> Can you move the __nvme_find_path call for the first path into
>> your round robing helper so that we can make this whole thing
>> a little cleaner?  E.g.
>>
>> 	if (head->subsys->iopolicy == NVME_IOPOLICY_RR)
>> 		return nvme_round_robin_path(head, node);
>>   	if (unlikely(!ns || !nvme_path_is_optimized(ns)))
>> 		ns = __nvme_find_path(head, node);
>> 	return ns;
>> Actually this order was by design.
> By ordering it _after_ __nvme_find_path() we guarantee that the first round 
> found an optimal path, and so we can continue selecting the next optimal 
> path.
> So this ordering would break the assumptions I did when implementing it.
> But I'll have a look to see if that can't be lifted.

You can keep the __nvme_find_path for round robin, I just want it moved
into the round robin helper, so that the main function stays nice and tidy.