From: Mike Snitzer <snitzer@redhat.com> To: Christoph Hellwig <hch@infradead.org>, Jens Axboe <axboe@kernel.dk> Cc: Ming Lei <ming.lei@redhat.com>, dm-devel@redhat.com, linux-block@vger.kernel.org Subject: Re: [PATCH 0/3] blk-mq/dm-rq: support BLK_MQ_F_BLOCKING for dm-rq Date: Tue, 11 Jan 2022 11:15:09 -0500 [thread overview] Message-ID: <Yd2tDWuP+aT3Hxbj@redhat.com> (raw) In-Reply-To: <Yd1BFpYTBlQSPReW@infradead.org> On Tue, Jan 11 2022 at 3:34P -0500, Christoph Hellwig <hch@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
WARNING: multiple messages have this Message-ID (diff)
From: Mike Snitzer <snitzer@redhat.com> To: Christoph Hellwig <hch@infradead.org>, Jens Axboe <axboe@kernel.dk> Cc: linux-block@vger.kernel.org, dm-devel@redhat.com, Ming Lei <ming.lei@redhat.com> Subject: Re: [dm-devel] [PATCH 0/3] blk-mq/dm-rq: support BLK_MQ_F_BLOCKING for dm-rq Date: Tue, 11 Jan 2022 11:15:09 -0500 [thread overview] Message-ID: <Yd2tDWuP+aT3Hxbj@redhat.com> (raw) In-Reply-To: <Yd1BFpYTBlQSPReW@infradead.org> On Tue, Jan 11 2022 at 3:34P -0500, Christoph Hellwig <hch@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 -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
next prev parent reply other threads:[~2022-01-11 16:15 UTC|newest] Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-12-21 14:14 [PATCH 0/3] blk-mq/dm-rq: support BLK_MQ_F_BLOCKING for dm-rq Ming Lei 2021-12-21 14:14 ` [dm-devel] " Ming Lei 2021-12-21 14:14 ` [PATCH 1/3] block: split having srcu from queue blocking Ming Lei 2021-12-21 14:14 ` [dm-devel] " Ming Lei 2022-01-11 18:13 ` Jeff Moyer 2022-01-11 18:13 ` Jeff Moyer 2021-12-21 14:14 ` [PATCH 2/3] block: add blk_alloc_disk_srcu Ming Lei 2021-12-21 14:14 ` [dm-devel] " Ming Lei 2022-01-11 18:13 ` Jeff Moyer 2022-01-11 18:13 ` Jeff Moyer 2021-12-21 14:14 ` [PATCH 3/3] dm: mark dm queue as blocking if any underlying is blocking Ming Lei 2021-12-21 14:14 ` [dm-devel] " Ming Lei 2022-01-06 15:40 ` Mike Snitzer 2022-01-06 15:40 ` [dm-devel] " Mike Snitzer 2022-01-06 15:51 ` Ming Lei 2022-01-06 15:51 ` [dm-devel] " Ming Lei 2022-01-10 19:23 ` Mike Snitzer 2022-01-10 19:23 ` [dm-devel] " Mike Snitzer 2022-01-11 18:14 ` Jeff Moyer 2022-01-11 18:14 ` Jeff Moyer 2021-12-21 16:21 ` [PATCH 0/3] blk-mq/dm-rq: support BLK_MQ_F_BLOCKING for dm-rq Christoph Hellwig 2021-12-21 16:21 ` [dm-devel] " Christoph Hellwig 2021-12-23 4:16 ` Ming Lei 2021-12-23 4:16 ` [dm-devel] " Ming Lei 2021-12-28 21:30 ` Mike Snitzer 2021-12-28 21:30 ` [dm-devel] " Mike Snitzer 2022-01-10 19:26 ` Mike Snitzer 2022-01-10 19:26 ` [dm-devel] " Mike Snitzer 2022-01-11 8:34 ` Christoph Hellwig 2022-01-11 8:34 ` Christoph Hellwig 2022-01-11 16:15 ` Mike Snitzer [this message] 2022-01-11 16:15 ` Mike Snitzer 2022-01-17 8:08 ` Christoph Hellwig 2022-01-17 8:08 ` Christoph Hellwig 2022-01-11 18:23 ` Jeff Moyer 2022-01-11 18:23 ` Jeff Moyer 2022-01-17 8:10 ` Christoph Hellwig 2022-01-17 8:10 ` Christoph Hellwig 2022-01-19 21:03 ` Mike Snitzer 2022-01-19 21:03 ` [dm-devel] " Mike Snitzer
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=Yd2tDWuP+aT3Hxbj@redhat.com \ --to=snitzer@redhat.com \ --cc=axboe@kernel.dk \ --cc=dm-devel@redhat.com \ --cc=hch@infradead.org \ --cc=linux-block@vger.kernel.org \ --cc=ming.lei@redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.