From: Christoph Hellwig <hch@lst.de>
To: Martin Wilck <martin.wilck@suse.com>
Cc: Christoph Hellwig <hch@lst.de>,
Benjamin Marzinski <bmarzins@redhat.com>,
Hannes Reinecke <hare@kernel.org>,
Mike Snitzer <snitzer@kernel.org>, Hannes Reinecke <hare@suse.de>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
James Bottomley <james.bottomley@hansenpartnership.com>,
linux-scsi@vger.kernel.org, dm-devel@lists.linux.dev
Subject: Re: [PATCH] scsi_lib: Align max_sectors to kb
Date: Mon, 22 Apr 2024 09:28:47 +0200 [thread overview]
Message-ID: <20240422072847.GA4605@lst.de> (raw)
In-Reply-To: <be267b46dd6bea6d82334d9d591c9a5054ff3b17.camel@suse.com>
On Fri, Apr 19, 2024 at 10:27:53AM +0200, Martin Wilck wrote:
> Well, it's just a matter of setting "queue_mode" in the multipath
> configuration.
Yes, and no. We'd probably at very last want a blk_plug callback to
allow making decisions for entire large I/Os instead of on a per-bio
basis.
> Mike has pointed out in 76e33fe4e2c4 that many of the original reasons
> for introducing request-based dm-multipath have been obsoleted by
> faster hardware and improvements in the generic block layer.
Yes.
> I am open for discussion on this subject, but with my distribution
> maintainer hat on, I don't expect the default being changed for end
> customers soon. Actually, with NVMe rising, I wonder if a major
> technology switch for dm-multipath (which is effectively SCSI multipath
> these days) makes sense at this point in time.
Well, it'll take ages until anything upstream gets into the enterprise
distros, which array users tend to use anyway. But I'd really love
to get the ball rolling upstream rather sooner than later even if there
is no need for immediate action. The reason is that request based
dm multipath causes a lot of special casing in the block core and
dm, and that has become a significant maintenance burden.
So if you have a chance to test the current bio based path, or help
with testing a plug callback (I can try to write a patch for that,
but I don't really have a good test setup) we can start to see where
we are in practice in terms of still needing the request based stacking,
and if there is a feasible path to move away from it.
prev parent reply other threads:[~2024-04-22 7:28 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20240418070015.27781-1-hare@kernel.org>
[not found] ` <20240418070304.GA26607@lst.de>
[not found] ` <5707dfc3-f8e2-4050-9bba-029facc32ca9@suse.de>
[not found] ` <20240418145129.GA32025@lst.de>
[not found] ` <410750a52af76fdc3bcf6265c9036037cb8141da.camel@suse.com>
[not found] ` <20240419062035.GA12480@lst.de>
2024-04-19 8:27 ` [PATCH] scsi_lib: Align max_sectors to kb Martin Wilck
2024-04-22 7:28 ` Christoph Hellwig [this message]
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=20240422072847.GA4605@lst.de \
--to=hch@lst.de \
--cc=bmarzins@redhat.com \
--cc=dm-devel@lists.linux.dev \
--cc=hare@kernel.org \
--cc=hare@suse.de \
--cc=james.bottomley@hansenpartnership.com \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=martin.wilck@suse.com \
--cc=snitzer@kernel.org \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).