All of lore.kernel.org
 help / color / mirror / Atom feed
From: Palmer Dabbelt <palmer@dabbelt.com>
To: snitzer@redhat.com
Cc: Christoph Hellwig <hch@infradead.org>,
	josef@toxicpanda.com, bvanassche@acm.org, corbet@lwn.net,
	kernel-team@android.com, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org,
	song@kernel.org, dm-devel@redhat.com,
	linux-kselftest@vger.kernel.org, shuah@kernel.org,
	agk@redhat.com, michael.christie@oracle.com
Subject: Re: [PATCH v1 0/5] dm: dm-user: New target that proxies BIOs to userspace
Date: Tue, 22 Dec 2020 12:38:28 -0800 (PST)	[thread overview]
Message-ID: <mhng-26d96d8e-77aa-415b-a8ee-518a0e91b6ef@palmerdabbelt-glaptop> (raw)
In-Reply-To: <20201222143616.GB12885@redhat.com>

On Tue, 22 Dec 2020 06:36:16 PST (-0800), snitzer@redhat.com wrote:
> On Tue, Dec 22 2020 at  8:32am -0500,
> Christoph Hellwig <hch@infradead.org> wrote:
>
>> On Mon, Dec 14, 2020 at 07:00:57PM -0800, Palmer Dabbelt wrote:
>> > I haven't gotten a whole lot of feedback, so I'm inclined to at least have some
>> > reasonable performance numbers before bothering with a v2.
>>
>> FYI, my other main worry beside duplicating nbd is that device mapper
>> really is a stacked interface that sits on top of other block device.
>> Turning this into something else that just pipes data to userspace
>> seems very strange.
>
> I agree.  Only way I'd be interested is if it somehow tackled enabling
> much more efficient IO.  Earlier discussion in this thread mentioned
> that zero-copy and low overhead wasn't a priority (because it is hard,
> etc).  But the hard work has already been done with io_uring.  If
> dm-user had a prereq of leaning heavily on io_uring and also enabled IO
> polling for bio-based then there may be a win to supporting it.
>
> But unless lower latency (or some other more significant win) is made
> possible I just don't care to prop up an unnatural DM bolt-on.

I don't remember if I mentioned this in the thread, but it was definately in
the Plumbers talk, but I'd had the general idea bouncing around that it would
be possible to write a high-performance version of this using an interface
similar to the one provided here while relying on io_uring for the
high-performance userspace.  That definately won't work with exactly the
current interface, but my hope was to avoid writing my own high-performance
ring buffer.  My worry was that it'll be too tricky to map this all to
zero-copy, and I guess I forgot about it.

Now that you bring it up, it certainly seems worth taking a shot at.  We'd
essentially have the best of both worlds: userspace implementations that want
to be simple could just use read()/write(), while those that want to be higher
performance could have their implicit ring buffer.

I'm currently trying to put together a benchmarking setup that is of sufficient
fidelity that I would believe the numbers, which is really why I don't have any
performance numbers yet (no sense posting numbers I would shoot down :)).  I'll
try to remember to take a shot at an io_uring based userspace (probably with
some dm-user interface modifications) to see how it feels.

WARNING: multiple messages have this Message-ID (diff)
From: Palmer Dabbelt <palmer@dabbelt.com>
To: snitzer@redhat.com
Cc: linux-raid@vger.kernel.org, bvanassche@acm.org, corbet@lwn.net,
	shuah@kernel.org, linux-doc@vger.kernel.org,
	josef@toxicpanda.com, linux-kernel@vger.kernel.org,
	Christoph Hellwig <hch@infradead.org>,
	song@kernel.org, dm-devel@redhat.com,
	michael.christie@oracle.com, linux-kselftest@vger.kernel.org,
	kernel-team@android.com, agk@redhat.com
Subject: Re: [dm-devel] [PATCH v1 0/5] dm: dm-user: New target that proxies BIOs to userspace
Date: Tue, 22 Dec 2020 12:38:28 -0800 (PST)	[thread overview]
Message-ID: <mhng-26d96d8e-77aa-415b-a8ee-518a0e91b6ef@palmerdabbelt-glaptop> (raw)
In-Reply-To: <20201222143616.GB12885@redhat.com>

On Tue, 22 Dec 2020 06:36:16 PST (-0800), snitzer@redhat.com wrote:
> On Tue, Dec 22 2020 at  8:32am -0500,
> Christoph Hellwig <hch@infradead.org> wrote:
>
>> On Mon, Dec 14, 2020 at 07:00:57PM -0800, Palmer Dabbelt wrote:
>> > I haven't gotten a whole lot of feedback, so I'm inclined to at least have some
>> > reasonable performance numbers before bothering with a v2.
>>
>> FYI, my other main worry beside duplicating nbd is that device mapper
>> really is a stacked interface that sits on top of other block device.
>> Turning this into something else that just pipes data to userspace
>> seems very strange.
>
> I agree.  Only way I'd be interested is if it somehow tackled enabling
> much more efficient IO.  Earlier discussion in this thread mentioned
> that zero-copy and low overhead wasn't a priority (because it is hard,
> etc).  But the hard work has already been done with io_uring.  If
> dm-user had a prereq of leaning heavily on io_uring and also enabled IO
> polling for bio-based then there may be a win to supporting it.
>
> But unless lower latency (or some other more significant win) is made
> possible I just don't care to prop up an unnatural DM bolt-on.

I don't remember if I mentioned this in the thread, but it was definately in
the Plumbers talk, but I'd had the general idea bouncing around that it would
be possible to write a high-performance version of this using an interface
similar to the one provided here while relying on io_uring for the
high-performance userspace.  That definately won't work with exactly the
current interface, but my hope was to avoid writing my own high-performance
ring buffer.  My worry was that it'll be too tricky to map this all to
zero-copy, and I guess I forgot about it.

Now that you bring it up, it certainly seems worth taking a shot at.  We'd
essentially have the best of both worlds: userspace implementations that want
to be simple could just use read()/write(), while those that want to be higher
performance could have their implicit ring buffer.

I'm currently trying to put together a benchmarking setup that is of sufficient
fidelity that I would believe the numbers, which is really why I don't have any
performance numbers yet (no sense posting numbers I would shoot down :)).  I'll
try to remember to take a shot at an io_uring based userspace (probably with
some dm-user interface modifications) to see how it feels.

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


  reply	other threads:[~2020-12-22 20:39 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-03 21:58 [PATCH v1 0/5] dm: dm-user: New target that proxies BIOs to userspace Palmer Dabbelt
2020-12-03 21:58 ` [dm-devel] " Palmer Dabbelt
2020-12-03 21:58 ` [PATCH v1 1/5] Documentation: Describe dm-user Palmer Dabbelt
2020-12-03 21:58   ` [dm-devel] " Palmer Dabbelt
2020-12-03 21:58 ` [PATCH v1 2/5] uapi: Add dm-user structure definition Palmer Dabbelt
2020-12-03 21:58   ` [dm-devel] " Palmer Dabbelt
2020-12-03 21:58 ` [PATCH v1 3/5] dm: dm-user: New target that proxies BIOs to userspace Palmer Dabbelt
2020-12-03 21:58   ` [dm-devel] " Palmer Dabbelt
2020-12-03 21:58 ` [PATCH v1 4/5] selftests/dm-user: A handful of tests for dm-user Palmer Dabbelt
2020-12-03 21:58   ` [dm-devel] " Palmer Dabbelt
2020-12-03 21:58 ` [PATCH v1 5/5] MAINTAINERS: Add myself as a dm-user maintainer Palmer Dabbelt
2020-12-03 21:58   ` [dm-devel] " Palmer Dabbelt
2020-12-04 10:33 ` [PATCH v1 0/5] dm: dm-user: New target that proxies BIOs to userspace Christoph Hellwig
2020-12-04 10:33   ` [dm-devel] " Christoph Hellwig
2020-12-07 18:55   ` Palmer Dabbelt
2020-12-07 18:55     ` [dm-devel] " Palmer Dabbelt
2020-12-10  3:38     ` Bart Van Assche
2020-12-10  3:38       ` Bart Van Assche
2020-12-10 17:03       ` Josef Bacik
2020-12-10 17:03         ` Josef Bacik
2020-12-15  3:00         ` Palmer Dabbelt
2020-12-15  3:00           ` Palmer Dabbelt
2020-12-16  6:17           ` Akira Hayakawa
2020-12-16 20:35             ` Palmer Dabbelt
2020-12-16 20:35               ` Palmer Dabbelt
2020-12-29 12:52               ` Akira Hayakawa
2020-12-16 18:24           ` Vitaly Mayatskih
2020-12-16 18:24             ` Vitaly Mayatskih
2020-12-17  6:55             ` Palmer Dabbelt
2020-12-17  6:55               ` Palmer Dabbelt
2020-12-22 13:32           ` Christoph Hellwig
2020-12-22 13:32             ` Christoph Hellwig
2020-12-22 14:36             ` Mike Snitzer
2020-12-22 14:36               ` [dm-devel] " Mike Snitzer
2020-12-22 20:38               ` Palmer Dabbelt [this message]
2020-12-22 20:38                 ` Palmer Dabbelt
2020-12-23  7:48                 ` Christoph Hellwig
2020-12-23  7:48                   ` [dm-devel] " Christoph Hellwig
2020-12-23 16:59                   ` Bart Van Assche
2020-12-23 16:59                     ` [dm-devel] " Bart Van Assche
2020-12-22 20:31             ` Palmer Dabbelt
2020-12-22 20:31               ` Palmer Dabbelt
2021-01-05 16:16       ` Desnoyers, Peter

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=mhng-26d96d8e-77aa-415b-a8ee-518a0e91b6ef@palmerdabbelt-glaptop \
    --to=palmer@dabbelt.com \
    --cc=agk@redhat.com \
    --cc=bvanassche@acm.org \
    --cc=corbet@lwn.net \
    --cc=dm-devel@redhat.com \
    --cc=hch@infradead.org \
    --cc=josef@toxicpanda.com \
    --cc=kernel-team@android.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=michael.christie@oracle.com \
    --cc=shuah@kernel.org \
    --cc=snitzer@redhat.com \
    --cc=song@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 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.