Re: RFC: split scsi passthrough fields out of struct request

[Christoph Hellwig]

On Wed, Jan 11, 2017 at 05:41:42PM -0500, Mike Snitzer wrote:
> I removed blk-mq on request_fn paths support because it was one of the
> permutations that I felt least useful/stable (see commit c5248f79f3 "dm:
> remove support for stacking dm-mq on .request_fn device(s)")
> 
> As for all of the different IO paths.  I've always liked the idea of
> blk-mq ruling the world.  With Jens' blk-mq IO scheduling advances maybe
> we're closer!

That removed blk-mq on top of request_fn code would do the right thing
for this series if it entirely replaced the old request_fn code in dm-mpath.
(as would the new bio code for that matter)
--
To unsubscribe from this list: send the line "unsubscribe linux-block" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RFC: split scsi passthrough fields out of struct request

[Christoph Hellwig]

Hi all,

this series splits the support for SCSI passthrough commands from the
main struct request used all over the block layer into a separate
scsi_request structure that drivers that want to support SCSI passthough
need to embedded as the first thing into their request-private data,
similar to how we handle NVMe passthrough commands.

To support this I've added support for that the private data after
request structure to the legacy request path instead, so that it can
be treated the same way as the blk-mq path.  Compare to the current
scsi_cmnd allocator that actually is a major simplification.

There is one major show-stopper for the series as-is:  Request-based
device mapper currently allocate the request structures in the stacking
driver without a knowledge of the queue it's going to be submitte on
for the legacy request path.  It managed to avoid that issue for the
blk-mq path, but that currently can't be used on legacy request devices
for reasons I don't fully understand.  We'll need to figure out how
sort this out, but maybe that's a good opportunity to drop one or two
of the three different dm-mpath I/O paths? :)

Note that the first two patches are 4.10 material and have already
been submitted independently.
--
To unsubscribe from this list: send the line "unsubscribe linux-block" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html