Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756058AbbFQN7S (ORCPT ); Wed, 17 Jun 2015 09:59:18 -0400 Received: from bombadil.infradead.org ([198.137.202.9]:59192 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755310AbbFQN7L (ORCPT ); Wed, 17 Jun 2015 09:59:11 -0400 Date: Wed, 17 Jun 2015 06:59:05 -0700 From: Christoph Hellwig To: Matias Bjorling Cc: Christoph Hellwig , Stephen.Bates@pmcs.com, keith.busch@intel.com, javier@lightnvm.io, linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org, axboe@fb.com, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v4 0/8] Support for Open-Channel SSDs Message-ID: <20150617135905.GA17119@infradead.org> References: <1433508870-28251-1-git-send-email-m@bjorling.me> <20150609074643.GA5707@infradead.org> <55787DDE.7020801@bjorling.me> <20150611102935.GA4419@infradead.org> <557C5787.3000608@bjorling.me> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <557C5787.3000608@bjorling.me> User-Agent: Mutt/1.5.23 (2014-03-12) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1671 Lines: 31 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/