Re: [PATCH 10/10] nvme: implement multipath access to nvme subsystems

[Sagi Grimberg <sagi@grimberg.me>]

>> the make_request
> 
> That basically just does a lookup (in a data structure we need for
> tracking the siblings inside nvme anyway) and the submits the
> I/O again.  The generic code all is in generic_make_request_fast.
> There are two more things which could move into common code, one
> reasonable, the other not:
> 
>   (1) the whole requeue_list list logic.  I thought about moving this
>       to the block layer as I'd also have some other use cases for it,
>       but decided to wait until those materialize to see if I'd really
>       need it.
>   (2) turning the logic inside out, e.g. providing a generic make_request
>       and supplying a find_path callback to it.  This would require (1)
>       but even then we'd save basically no code, add an indirect call
>       in the fast path and make things harder to read.  This actually
>       is how I started out and didn't like it.
> 
>> and failover logic
> 
> The big thing about the failover logic is looking a the detailed error
> codes and changing the controller state, all of which is fundamentally
> driver specific.  The only thing that could reasonably be common is
> the requeue_list handling as mentioned above.  Note that this will
> become even more integrated with the nvme driver once ANA support
> lands.

Not arguing with you at all, you obviously gave it a lot of thought.

I thought your multipathing code would really live in the block
layer and only require something really basic from nvme (which could
easily be applied on other drivers). But I do understand it might
create a lot of churn.

btw, why are partial completions something that can't be done
without cloning the bio? is it possible to clone the bio once from the
completion flow when you see that you got a partial completion?