lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 22 Dec 2020 12:38:28 -0800 (PST) From: Palmer Dabbelt <palmer@...belt.com> To: snitzer@...hat.com CC: Christoph Hellwig <hch@...radead.org>, josef@...icpanda.com, bvanassche@....org, corbet@....net, kernel-team@...roid.com, linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org, linux-raid@...r.kernel.org, song@...nel.org, dm-devel@...hat.com, linux-kselftest@...r.kernel.org, shuah@...nel.org, agk@...hat.com, michael.christie@...cle.com Subject: Re: [PATCH v1 0/5] dm: dm-user: New target that proxies BIOs to userspace On Tue, 22 Dec 2020 06:36:16 PST (-0800), snitzer@...hat.com wrote: > On Tue, Dec 22 2020 at 8:32am -0500, > Christoph Hellwig <hch@...radead.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.
Powered by blists - more mailing lists