[dm-devel] [Lsf] dm-mpath request merging concerns [was: Re: It's time to put together the schedule]

[Christoph Hellwig]

On Mon, Feb 23, 2015 at 02:50:57PM -0500, Mike Snitzer wrote:
> - Should request-based DM wire up blk_check_plugged() to allow the block
>   layer's plugging to more directly influence when blk_start_request()
>   is called from dm_request_fn?
> 
> - Put differently: in addition to checking ->busy should dm_request_fn
>   also maintain and check plugging state that is influenced by
>   blk_check_plugged()?
> 
> (or is this moot given that the block layer will only call q->request_fn
> when the queue isn't plugged anyway!?)
> 
> Basically the long and short of this is: the block layer isn't helping
> us like we thought (elevator is effectively useless and/or being
> circumvented).  And this apparently isn't new.
> 
> I'll take a more measured look at all of this while also trying to
> make sense of switching request-based DM over to using blk-mq.

I'd like to rephrase the question a little bit:  Is the request layer +
device mapper really the right combination for driving multipath I/O?

If we were moving it to a set of helpers where blk-mq drivers could
just ask for resubmitting I/O on another device of it's choice we
would be able to cut the middle man with all the problems that having
a middle man entails. That is all the busy checks that need to be
propagated, the plugging question, the various merge parameters that need
to be communicated from the driver, the sense code intepretation for which
dm needs to call back into SCSI (or NVMe for that matter).  To me
it seems like a much better idea to let the driver (*) driver the
decision, with a few library helpers provided to deal with queue selection
algorithms and other faіrly generic pieces of code.

(*) that is block layer driver, in case of SCSI it would still be the
midlayer pulling the strings.