linux-kernel - Re: [PATCH v4 0/8] Support for Open-Channel SSDs

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 17 Jun 2015 06:59:05 -0700
From:	Christoph Hellwig <hch@...radead.org>
To:	Matias Bjorling <m@...rling.me>
Cc:	Christoph Hellwig <hch@...radead.org>, Stephen.Bates@...s.com,
	keith.busch@...el.com, javier@...htnvm.io,
	linux-kernel@...r.kernel.org, linux-nvme@...ts.infradead.org,
	axboe@...com, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH v4 0/8] Support for Open-Channel SSDs

On Sat, Jun 13, 2015 at 06:17:11PM +0200, Matias Bjorling wrote:
> > Note that for NVMe it might still make sense to implement this using
> > blk-mq and a struct request, but those should be internal similar to
> > how NVMe implements admin commands.
> 
> How about handling I/O merges? In the case where a block API is exposed
> with a global FTL, filesystems relies on I/O merges for improving
> performance. If using internal commands, merging has to implemented in
> the lightnvm stack itself, I rather want to use blk-mq and not duplicate
> the effort. I've kept the stacking model, so that I/Os go through the
> queue I/O path and then picked up in the device driver.

I don't think the current abuses of the block API are acceptable though.
The crazy deep merging shouldn't be too relevant for SSD-type devices
so I think you'd do better than trying to reuse the TYPE_FS level
blk-mq merging code.  If you want to reuse the request
allocation/submission code that's still doable.

As a start add a new submit_io method to the nvm_dev_ops, and add
an implementation similar to pscsi_execute_cmd in
drivers/target/target_core_pscsi.c for nvme, and a trivial no op
for a null-nvm driver replacing the null-blk additions.  This
will give you very similar behavior to your current code, while
allowing to drop all the hacks in the block code.  Note that simple
plugging will work just fine which should be all you'll need.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/