[dm-devel] [PATCH 0/3] blk-mq/dm-rq: support BLK_MQ_F_BLOCKING for dm-rq
Mike Snitzer
snitzer at redhat.com
Tue Jan 11 16:15:09 UTC 2022
On Tue, Jan 11 2022 at 3:34P -0500,
Christoph Hellwig <hch at infradead.org> wrote:
> On Tue, Dec 28, 2021 at 04:30:08PM -0500, Mike Snitzer wrote:
> > Yeah, people use request-based for IO scheduling and more capable path
> > selectors. Imposing bio-based would be a pretty jarring workaround for
> > BLK_MQ_F_BLOCKING. request-based DM should properly support it.
>
> Given that nvme-tcp is the only blocking driver that has multipath
> driver that driver explicitly does not intend to support dm-multipath
> I'm absolutely against adding block layer cruft for this particular
> use case.
this diffstat amounts to what you call "cruft":
block/blk-core.c | 2 +-
block/blk-mq.c | 6 +++---
block/blk-mq.h | 2 +-
block/blk-sysfs.c | 2 +-
block/genhd.c | 5 +++--
drivers/md/dm-rq.c | 5 ++++-
drivers/md/dm-rq.h | 3 ++-
drivers/md/dm-table.c | 14 ++++++++++++++
drivers/md/dm.c | 5 +++--
drivers/md/dm.h | 1 +
include/linux/blkdev.h | 5 +++--
include/linux/genhd.h | 12 ++++++++----
12 files changed, 44 insertions(+), 18 deletions(-)
> SCSI even has this:
>
> /*
> * SCSI never enables blk-mq's BLK_MQ_F_BLOCKING flag so
> * calling synchronize_rcu() once is enough.
> */
> WARN_ON_ONCE(shost->tag_set.flags & BLK_MQ_F_BLOCKING);
>
Round and round we go.. Pretty tired of this.
You are perfectly fine with incrementally compromising request-based
DM's ability to evolve as block core does.
Seriously, this patchset shouldn't warrant bickering:
https://patchwork.kernel.org/project/dm-devel/list/?series=598823
Jens, this incremental weakening of what it is that DM is allowed to
do is not something I can continue to work with (nor should Ming's or
others' contributions be rejected for such reasons).
This tribal war needs to stop.
Mike
More information about the dm-devel
mailing list