From: "Javier González" <jg@lightnvm.io> To: Christoph Hellwig <hch@infradead.org> Cc: "Matias Bjørling" <m@bjorling.me>, "Jens Axboe" <axboe@kernel.dk>, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [GIT PULL 24/25] lightnvm: pblk: add iostat support Date: Mon, 8 Jan 2018 13:53:11 +0100 [thread overview] Message-ID: <EC97E53B-ECF3-4EB6-B92A-3950EEFF8580@lightnvm.io> (raw) In-Reply-To: <20180108115457.GA28922@infradead.org> > On 8 Jan 2018, at 12.54, Christoph Hellwig <hch@infradead.org> wrote: >=20 > On Fri, Jan 05, 2018 at 07:33:36PM +0100, Matias Bj=C3=B8rling wrote: >> On 01/05/2018 04:42 PM, Jens Axboe wrote: >>> On Fri, Jan 05 2018, Matias Bj=C3=B8rling wrote: >>>> From: Javier Gonz=C3=A1lez <javier@cnexlabs.com> >>>>=20 >>>> Since pblk registers its own block device, the iostat accounting is >>>> not automatically done for us. Therefore, add the necessary >>>> accounting logic to satisfy the iostat interface. >>>=20 >>> Ignorant question - why is it a raw block device, not using blk-mq? >>=20 >> The current flow is using the raw block device, together with the = blk-mq >> nvme device driver. A bio is sent down to the nvme_nvm_submit_io() = path in >> the /drivers/nvme/host/lightnvm.c file. =46rom there it attaches the = to NVMe >> blk-mq implementation. >>=20 >> Is there a better way to do it? >=20 > I suspect the right way to do things is to split NVMe for different > I/O command sets, and make this an I/O command set. This makes sense. This was actually how I implemented it to start with, but I changed it to be less intrusive on the nvme path. Let's revert the patch and we can add it back when we push the 2.0 patches. > But before touching much of NVMe, I'd really, really like to see an > actual spec first. The 2.0 spec. is open and is available here [1]. I thought you had looked into it already... Anyway, feedback is more than welcome. [1] = https://docs.google.com/document/d/1kedBY_1-hfkAlqT4EdwY6gz-6UOZbn7kIjWpmB= LPNj0 Javier=
WARNING: multiple messages have this Message-ID (diff)
From: "Javier González" <jg@lightnvm.io> To: Christoph Hellwig <hch@infradead.org> Cc: "Matias Bjørling" <m@bjorling.me>, "Jens Axboe" <axboe@kernel.dk>, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [GIT PULL 24/25] lightnvm: pblk: add iostat support Date: Mon, 8 Jan 2018 13:53:11 +0100 [thread overview] Message-ID: <EC97E53B-ECF3-4EB6-B92A-3950EEFF8580@lightnvm.io> (raw) In-Reply-To: <20180108115457.GA28922@infradead.org> > On 8 Jan 2018, at 12.54, Christoph Hellwig <hch@infradead.org> wrote: > > On Fri, Jan 05, 2018 at 07:33:36PM +0100, Matias Bjørling wrote: >> On 01/05/2018 04:42 PM, Jens Axboe wrote: >>> On Fri, Jan 05 2018, Matias Bjørling wrote: >>>> From: Javier González <javier@cnexlabs.com> >>>> >>>> Since pblk registers its own block device, the iostat accounting is >>>> not automatically done for us. Therefore, add the necessary >>>> accounting logic to satisfy the iostat interface. >>> >>> Ignorant question - why is it a raw block device, not using blk-mq? >> >> The current flow is using the raw block device, together with the blk-mq >> nvme device driver. A bio is sent down to the nvme_nvm_submit_io() path in >> the /drivers/nvme/host/lightnvm.c file. From there it attaches the to NVMe >> blk-mq implementation. >> >> Is there a better way to do it? > > I suspect the right way to do things is to split NVMe for different > I/O command sets, and make this an I/O command set. This makes sense. This was actually how I implemented it to start with, but I changed it to be less intrusive on the nvme path. Let's revert the patch and we can add it back when we push the 2.0 patches. > But before touching much of NVMe, I'd really, really like to see an > actual spec first. The 2.0 spec. is open and is available here [1]. I thought you had looked into it already... Anyway, feedback is more than welcome. [1] https://docs.google.com/document/d/1kedBY_1-hfkAlqT4EdwY6gz-6UOZbn7kIjWpmBLPNj0 Javier
next prev parent reply other threads:[~2018-01-08 12:53 UTC|newest] Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-01-05 13:15 [GIT PULL 00/25] LightNVM updates for 4.16 Matias Bjørling 2018-01-05 13:15 ` [GIT PULL 01/25] null_blk: remove lightnvm support Matias Bjørling 2018-01-05 13:15 ` [GIT PULL 02/25] lightnvm: remove rrpc Matias Bjørling 2018-01-05 13:15 ` [GIT PULL 03/25] lightnvm: use internal pblk methods Matias Bjørling 2018-01-05 13:16 ` [GIT PULL 04/25] lightnvm: remove hybrid ocssd 1.2 support Matias Bjørling 2018-01-05 13:16 ` [GIT PULL 05/25] lightnvm: remove unnecessary field from nvm_rq Matias Bjørling 2018-01-05 13:16 ` [GIT PULL 06/25] lightnvm: remove lower page tables Matias Bjørling 2018-01-05 13:16 ` [GIT PULL 07/25] lightnvm: make geometry structures 2.0 ready Matias Bjørling 2018-01-05 13:16 ` [GIT PULL 08/25] lightnvm: refactor target type lookup Matias Bjørling 2018-01-05 13:16 ` [GIT PULL 09/25] lightnvm: guarantee target unique name across devs Matias Bjørling 2018-01-05 13:16 ` [GIT PULL 10/25] lightnvm: pblk: compress and reorder helper functions Matias Bjørling 2018-01-05 13:16 ` [GIT PULL 11/25] lightnvm: pblk: remove pblk_for_each_lun helper Matias Bjørling 2018-01-05 13:16 ` [GIT PULL 12/25] lightnvm: pblk: refactor emeta consistency check Matias Bjørling 2018-01-05 13:16 ` [GIT PULL 13/25] lightnvm: pblk: rename sync_point to flush_point Matias Bjørling 2018-01-05 13:16 ` [GIT PULL 14/25] lightnvm: pblk: clear flush point on completed writes Matias Bjørling 2018-01-05 13:16 ` [GIT PULL 15/25] lightnvm: pblk: prevent premature sync point resets Matias Bjørling 2018-01-05 13:16 ` [GIT PULL 16/25] lightnvm: pblk: remove pblk_gc_stop Matias Bjørling 2018-01-05 13:16 ` [GIT PULL 17/25] lightnvm: pblk: use exact free block counter in RL Matias Bjørling 2018-01-05 13:16 ` [GIT PULL 18/25] lightnvm: set target over-provision on create ioctl Matias Bjørling 2018-01-05 19:33 ` Randy Dunlap 2018-01-05 19:52 ` Javier Gonzalez 2018-01-05 19:53 ` Matias Bjørling 2018-01-05 19:56 ` Javier Gonzalez 2018-01-05 20:17 ` Randy Dunlap 2018-01-05 13:16 ` [GIT PULL 19/25] lightnvm: pblk: ignore high ecc errors on recovery Matias Bjørling 2018-01-05 13:16 ` [GIT PULL 20/25] lightnvm: pblk: do not log recovery read errors Matias Bjørling 2018-01-05 13:16 ` [GIT PULL 21/25] lightnvm: pblk: ensure kthread alloc. before kicking it Matias Bjørling 2018-01-05 13:16 ` [GIT PULL 22/25] lightnvm: pblk: free write buffer on init failure Matias Bjørling 2018-01-05 13:16 ` [GIT PULL 23/25] lightnvm: pblk: print instance name on instance info Matias Bjørling 2018-01-05 13:16 ` [GIT PULL 24/25] lightnvm: pblk: add iostat support Matias Bjørling 2018-01-05 15:42 ` Jens Axboe 2018-01-05 15:42 ` Jens Axboe 2018-01-05 18:33 ` Matias Bjørling 2018-01-05 18:33 ` Matias Bjørling 2018-01-08 11:54 ` Christoph Hellwig 2018-01-08 11:54 ` Christoph Hellwig 2018-01-08 12:53 ` Javier González [this message] 2018-01-08 12:53 ` Javier González 2018-01-08 13:31 ` Matias Bjørling 2018-01-08 13:31 ` Matias Bjørling 2018-01-05 13:16 ` [GIT PULL 25/25] lightnvm: pblk: refactor pblk_ppa_comp function Matias Bjørling 2018-01-05 15:50 ` [GIT PULL 00/25] LightNVM updates for 4.16 Jens Axboe 2018-01-05 15:50 ` Jens Axboe 2018-01-05 18:34 ` Matias Bjørling 2018-01-05 18:34 ` Matias Bjørling
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=EC97E53B-ECF3-4EB6-B92A-3950EEFF8580@lightnvm.io \ --to=jg@lightnvm.io \ --cc=axboe@kernel.dk \ --cc=hch@infradead.org \ --cc=linux-block@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=m@bjorling.me \ /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: linkBe 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.