On Fri, Jul 14 2017 at 1:17pm -0400, Ewan D. Milne <emilne@xxxxxxxxxx> wrote: > On Fri, 2017-07-14 at 10:19 -0400, Mike Snitzer wrote: > > > > Do you see a benefit to extracting that portion of your WIP patch > > (removing the ->complete handler entirely)? > > > > Or leave well enough alone and just continue to disable dm-mq's ability > > to stack on .request_fn paths? > > > > Given SCSI's switch to scsi-mq by default I cannot see value in propping > > up stacking on the old .request_fn devices. > > So, the dm_mod.use_blk_mq flag is global, right? I guess the question > is whether all of the block device types used on a system under DM are > supported under MQ. If that is the case then we would be OK. I didn't quite understand Ewan's question so we talked in person. His concern was whether other DM targets needed to be worried about blk-mq vs not. I clarified that DM multipath is the only target that is request-based and that it is fine with stacking on scsi-mq. And all the bio-based targets obviously stack just fine on scsi-mq devices. > The other question is whether there are negative performance > consequences in any (corner?) cases with MQ that would result in it > being preferable to run in non-MQ mode (e.g. tag space with lpfc, did > we ever resolve that?) but the right approach there is to put the effort > into the MQ path going forward, as has been the case. Yeap.
