All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Snitzer <snitzer@kernel.org>
To: John Meneghini <jmeneghi@redhat.com>
Cc: "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	dm-devel@lists.linux.dev, Samuel Petrovic <spetrovi@redhat.com>,
	Benjamin Marzinski <bmarzins@redhat.com>,
	Mikulas Patocka <mpatocka@redhat.com>
Subject: Re: [LSF/MM/BPF TOPIC] Multipath bio vs. request
Date: Mon, 24 Mar 2025 16:23:22 -0400	[thread overview]
Message-ID: <Z-G_Oj7C4wmLaJnT@kernel.org> (raw)
In-Reply-To: <Z-G-fAHSygeJuPBV@kernel.org>

On Mon, Mar 24, 2025 at 04:20:12PM -0400, Mike Snitzer wrote:
> Hi John,
> 
> On Sat, Mar 22, 2025 at 02:38:29PM -0400, John Meneghini wrote:
> > I will be presenting on this topic at LSF/MM/BPF this year, in the IO track.
> > 
> > Here's an introduction for my talk.
> > 
> > DMMP currently supports two different kernel IO interfaces: the BIO interface[1] (struct bio) and the Request interface[2] (struct request).
> > By default DMMP uses the Request interface and over the years much work has been done test and improve the performance of the DMMP Request
> > interface. DMMP can also be manually configured to use the BIO interface. The DMMP BIO interface is supported but little work has been done
> > to test and improve its performance. DMMP is currently the only upstream component which continues to use the Request interface for submitting IO.
> 
> As I clarified at lunch today, your "DMMP is currently the only
> upstream component which continues to use the Request interface for
> submitting IO." makes no sense to me.  The request-based DM multipath
> target is a blk-mq driver.  It just acts like most blk-mq drivers.
> 
> What is different is DM core's request-based code will clone each
> request that gets submitted to the request-based DMMP device.  And
> then when the request is submitted to an underlying path it gets
> directly inserted in the unlering blk-mq request-queue for that path.

Sorry for typoe: s/unlering/underlying/
 
> So in those aspects request-based DM core and DM multipath are unique
> and they do require block interfaces that only benefit DMMP -- but
> that has _always_ been the case (nothing else ever needed to clone
> requests before submitting them).
> 
> > At the ALPSS 2024 conference last October we discussed the possibility of deprecating and eventually removing support the Request interface
> > as kernel API. Such a change could impact DMMP so I was asked if Red Hat would be willing to support the effort by measuring the performance
> > of DMMP's BIO interface[3] and comparing it to its Request based performance. Having such a comparative performance analysis would be very helpful
> > in determining what further changes might be needed to move DMMP away from using the Request interface. This would help with the overall effort
> > to improve BIO interface performance and eventually remove support for Request based IO as a kernel API.
> > 
> > In this presentation I will share the preliminary results of Red Hat's DMMP BIO vs Request performance tests[4] and discuss what the next possible
> > steps could be for moving forward.
> > 
> > The tests and performance graphs in this presentation were developed and run by Samuel Petrovic <spetrovi@redhat.com>.
> > Credit goes to Samuel for creating these performance tests and many thanks to Benjamin Marzinski <bmarzins@redhat.com>,
> > Mikulas Patocka <mpatocka@redhat.com> and others on the Red Hat DMMP and Performance teams who contributed to this work.
> > 
> > [1] https://lwn.net/Articles/736534/
> > [2] https://lwn.net/Articles/738449/
> > [3] https://lore.kernel.org/linux-scsi/643e61a8-b0cb-4c9d-831a-879aa86d888e@redhat.com
> > [4] https://people.redhat.com/jmeneghi/LSFMM_2025/DMMP_BIOvsRequest/
> 
> Other useful context is the 2007 paper that provides an overview of
> why dm-multipath was switched from bio-based to request-based:
> https://www.kernel.org/doc/ols/2007/ols2007v2-pages-235-244.pdf
> 

  reply	other threads:[~2025-03-24 20:23 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-22 18:38 [LSF/MM/BPF TOPIC] Multipath bio vs. request John Meneghini
2025-03-24 20:20 ` Mike Snitzer
2025-03-24 20:23   ` Mike Snitzer [this message]
2025-03-25  2:59 ` Mike Christie

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=Z-G_Oj7C4wmLaJnT@kernel.org \
    --to=snitzer@kernel.org \
    --cc=bmarzins@redhat.com \
    --cc=dm-devel@lists.linux.dev \
    --cc=jmeneghi@redhat.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mpatocka@redhat.com \
    --cc=spetrovi@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: link
Be 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.