Re: [PATCH v32 0/4] scsi: ufs: Add Host Performance Booster Support

2021-04-06 Thread Javier Gonzalez
On 31.03.2021 21:40, Bean Huo wrote: Hi Martin I don't know when/how do you plan to accept this patch. I think the Mobile vendors and chipset vendors are all looking forward to this UFS HPB feature that can be mainlined in the upstream Linux. Since the first version HPB driver submitted in the

Re: [PATCH 2/2] nvme: add emulation for zone-append

2020-08-20 Thread Javier Gonzalez
On 20.08.2020 13:07, Kanchan Joshi wrote: On Thu, Aug 20, 2020 at 3:22 AM Keith Busch wrote: On Wed, Aug 19, 2020 at 01:11:58PM -0600, David Fugate wrote: > Intel does not support making *optional* NVMe spec features *required* > by the NVMe driver. This is inaccurate. As another example,

Re: [PATCH 2/2] nvme: add emulation for zone-append

2020-08-20 Thread Javier Gonzalez
On 20.08.2020 08:52, Christoph Hellwig wrote: On Thu, Aug 20, 2020 at 08:37:19AM +0200, Javier Gonzalez wrote: We will stop pushing for this emulation. We have a couple of SSDs where we disabled Append, we implemented support for them, and we wanted to push the changes upstream. That's

Re: [PATCH 2/2] nvme: add emulation for zone-append

2020-08-20 Thread Javier Gonzalez
On 19.08.2020 12:43, Christoph Hellwig wrote: On Wed, Aug 19, 2020 at 09:14:13AM +, Damien Le Moal wrote: While defining a zone append command for SCSI/ZBC is possible (using sense data for returning the written offset), there is no way to define zone append for SATA/ZAC without entirely

Re: [PATCH 2/2] nvme: add emulation for zone-append

2020-08-20 Thread Javier Gonzalez
On 19.08.2020 13:25, Jens Axboe wrote: On 8/19/20 12:11 PM, David Fugate wrote: On Tue, 2020-08-18 at 07:12 +, Christoph Hellwig wrote: On Tue, Aug 18, 2020 at 10:59:36AM +0530, Kanchan Joshi wrote: If drive does not support zone-append natively, enable emulation using regular write. Make

Re: [PATCH 2/2] nvme: add emulation for zone-append

2020-08-19 Thread Javier Gonzalez
On 19.08.2020 09:40, Christoph Hellwig wrote: On Tue, Aug 18, 2020 at 08:04:28PM +0200, Javier Gonzalez wrote: I understand that you want vendor alignment in the NVMe driver and I agree. We are not pushing for a non-append model - you can see that we are investing effort in implementing

Re: [PATCH 2/2] nvme: add emulation for zone-append

2020-08-18 Thread Javier Gonzalez
On 18.08.2020 10:39, Keith Busch wrote: On Tue, Aug 18, 2020 at 07:29:12PM +0200, Javier Gonzalez wrote: On 18.08.2020 09:58, Keith Busch wrote: > On Tue, Aug 18, 2020 at 11:50:33AM +0200, Javier Gonzalez wrote: > > a number of customers are requiring the use of normal writes, which we

Re: [PATCH 2/2] nvme: add emulation for zone-append

2020-08-18 Thread Javier Gonzalez
On 18.08.2020 12:51, Matias Bjørling wrote: On 18/08/2020 11.50, Javier Gonzalez wrote: On 18.08.2020 09:12, Christoph Hellwig wrote: On Tue, Aug 18, 2020 at 10:59:36AM +0530, Kanchan Joshi wrote: If drive does not support zone-append natively, enable emulation using regular write. Make

Re: [PATCH 2/2] nvme: add emulation for zone-append

2020-08-18 Thread Javier Gonzalez
On 18.08.2020 17:50, Christoph Hellwig wrote: On Tue, Aug 18, 2020 at 11:50:33AM +0200, Javier Gonzalez wrote: I understand that the NVMe process was agitated and that the current ZNS implementation in Linux relies in append support from the device perspective. However, the current TP does

Re: [PATCH 2/2] nvme: add emulation for zone-append

2020-08-18 Thread Javier Gonzalez
On 18.08.2020 09:58, Keith Busch wrote: On Tue, Aug 18, 2020 at 11:50:33AM +0200, Javier Gonzalez wrote: a number of customers are requiring the use of normal writes, which we want to support. A device that supports append is completely usable for those customers, too. There's no need

Re: [PATCH 2/2] nvme: add emulation for zone-append

2020-08-18 Thread Javier Gonzalez
On 18.08.2020 09:12, Christoph Hellwig wrote: On Tue, Aug 18, 2020 at 10:59:36AM +0530, Kanchan Joshi wrote: If drive does not support zone-append natively, enable emulation using regular write. Make emulated zone-append cmd write-lock the zone, preventing concurrent append/write on the same

Re: [PATCH 1/3] lightnvm: pblk: refactor metadata paths

2018-08-29 Thread Javier Gonzalez
> On 29 Aug 2018, at 15.02, Matias Bjørling wrote: > > On 08/29/2018 10:56 AM, Javier González wrote: >> pblk maintains two different metadata paths for smeta and emeta, which >> store metadata at the start of the line and at the end of the line, >> respectively. Until now, these path has been

Re: [PATCH 1/3] lightnvm: pblk: refactor metadata paths

2018-08-29 Thread Javier Gonzalez
> On 29 Aug 2018, at 15.02, Matias Bjørling wrote: > > On 08/29/2018 10:56 AM, Javier González wrote: >> pblk maintains two different metadata paths for smeta and emeta, which >> store metadata at the start of the line and at the end of the line, >> respectively. Until now, these path has been

Re: [PATCH] lightnvm: pblk: fix rqd.error return value in pblk_blk_erase_sync

2018-08-03 Thread Javier Gonzalez
> On 2 Aug 2018, at 22.50, Matias Bjørling wrote: > > rqd.error is masked by the return value of pblk_submit_io_sync. > The rqd structure is then passed on to the end_io function, which > assumes that any error should lead to a chunk being marked > offline/bad. Since the pblk_submit_io_sync can

Re: [PATCH] lightnvm: pblk: fix rqd.error return value in pblk_blk_erase_sync

2018-08-03 Thread Javier Gonzalez
> On 2 Aug 2018, at 22.50, Matias Bjørling wrote: > > rqd.error is masked by the return value of pblk_submit_io_sync. > The rqd structure is then passed on to the end_io function, which > assumes that any error should lead to a chunk being marked > offline/bad. Since the pblk_submit_io_sync can

Re: [PATCH v2] lightnvm: pblk: expose generic disk name on pr_* msgs

2018-06-29 Thread Javier Gonzalez
> On 29 Jun 2018, at 13.22, Matias Bjørling wrote: > > On 06/29/2018 01:07 PM, Javier Gonzalez wrote: >>> On 29 Jun 2018, at 12.59, Matias Bjørling wrote: >>> >>> On 06/29/2018 11:36 AM, Javier Gonzalez wrote: >>>>> On 28 Jun 2018, at 15

Re: [PATCH v2] lightnvm: pblk: expose generic disk name on pr_* msgs

2018-06-29 Thread Javier Gonzalez
> On 29 Jun 2018, at 13.22, Matias Bjørling wrote: > > On 06/29/2018 01:07 PM, Javier Gonzalez wrote: >>> On 29 Jun 2018, at 12.59, Matias Bjørling wrote: >>> >>> On 06/29/2018 11:36 AM, Javier Gonzalez wrote: >>>>> On 28 Jun 2018, at 15

Re: [PATCH] lightnvm: pblk: limit get chk meta request size

2018-06-12 Thread Javier Gonzalez
> On 12 Jun 2018, at 03.30, Matias Bjørling wrote: > > For devices that does not specify a limit on its transfer size, the > get_chk_meta command may send down a single I/O retrieving the full > chunk metadata table. Resulting in large 2-4MB I/O requests. Instead, > split up the I/Os to a

Re: [PATCH] lightnvm: pblk: limit get chk meta request size

2018-06-12 Thread Javier Gonzalez
> On 12 Jun 2018, at 03.30, Matias Bjørling wrote: > > For devices that does not specify a limit on its transfer size, the > get_chk_meta command may send down a single I/O retrieving the full > chunk metadata table. Resulting in large 2-4MB I/O requests. Instead, > split up the I/Os to a

Re: [GIT PULL 20/20] lightnvm: pblk: sync RB and RL states during GC

2018-05-28 Thread Javier Gonzalez
Javier I somehow missed these patches in the mailing list. Sorry for coming with feedback this late. I'll look at my filters - in any case, would you mind Cc'ing me in the future? > On 28 May 2018, at 10.58, Matias Bjørling wrote: > > From: Igor Konopko

Re: [GIT PULL 20/20] lightnvm: pblk: sync RB and RL states during GC

2018-05-28 Thread Javier Gonzalez
Javier I somehow missed these patches in the mailing list. Sorry for coming with feedback this late. I'll look at my filters - in any case, would you mind Cc'ing me in the future? > On 28 May 2018, at 10.58, Matias Bjørling wrote: > > From: Igor Konopko > > During sequential workloads we can

Re: [GIT PULL 16/20] lightnvm: error handling when whole line is bad

2018-05-28 Thread Javier Gonzalez
> On 28 May 2018, at 10.58, Matias Bjørling wrote: > > From: Igor Konopko > > When all the blocks (chunks) in line are marked as bad (offline) > we shouldn't try to read smeta during init process. > > Currently we are trying to do so by passing -1

Re: [GIT PULL 16/20] lightnvm: error handling when whole line is bad

2018-05-28 Thread Javier Gonzalez
> On 28 May 2018, at 10.58, Matias Bjørling wrote: > > From: Igor Konopko > > When all the blocks (chunks) in line are marked as bad (offline) > we shouldn't try to read smeta during init process. > > Currently we are trying to do so by passing -1 as PPA address, > what causes multiple

Re: [GIT PULL 18/20] lightnvm: pblk: handle case when mw_cunits equals to 0

2018-05-28 Thread Javier Gonzalez
> On 28 May 2018, at 10.58, Matias Bjørling wrote: > > From: Marcin Dziegielewski > > Some devices can expose mw_cunits equal to 0, it can cause creation > of too small write buffer and cause performance to drop on write > workloads. > > To

Re: [GIT PULL 18/20] lightnvm: pblk: handle case when mw_cunits equals to 0

2018-05-28 Thread Javier Gonzalez
> On 28 May 2018, at 10.58, Matias Bjørling wrote: > > From: Marcin Dziegielewski > > Some devices can expose mw_cunits equal to 0, it can cause creation > of too small write buffer and cause performance to drop on write > workloads. > > To handle that, we use the default value for MLC and

Re: [PATCH 04/12] lightnvm: convert to bioset_init()/mempool_init()

2018-05-22 Thread Javier Gonzalez
> On 21 May 2018, at 00.25, Kent Overstreet wrote: > > Signed-off-by: Kent Overstreet > --- > drivers/lightnvm/pblk-core.c | 30 ++--- > drivers/lightnvm/pblk-init.c | 72 >

Re: [PATCH 04/12] lightnvm: convert to bioset_init()/mempool_init()

2018-05-22 Thread Javier Gonzalez
> On 21 May 2018, at 00.25, Kent Overstreet wrote: > > Signed-off-by: Kent Overstreet > --- > drivers/lightnvm/pblk-core.c | 30 ++--- > drivers/lightnvm/pblk-init.c | 72 > drivers/lightnvm/pblk-read.c | 4 +- >

Re: [PATCH v2 3/3] lightnvm: pblk: fix smeta write error path

2018-04-30 Thread Javier Gonzalez
> On 24 Apr 2018, at 07.45, Hans Holmberg > wrote: > > From: Hans Holmberg > > Smeta write errors were previously ignored. Skip these > lines instead and throw them back on the free > list, so the chunks will go through a reset cycle

Re: [PATCH v2 2/3] lightnvm: pblk: garbage collect lines with failed writes

2018-04-30 Thread Javier Gonzalez
> On 30 Apr 2018, at 11.14, Javier Gonzalez <jav...@cnexlabs.com> wrote: > >> On 24 Apr 2018, at 07.45, Hans Holmberg <hans.ml.holmb...@owltronix.com> >> wrote: >> >> From: Hans Holmberg <hans.holmb...@cnexlabs.com> >> >> Write

Re: [PATCH v2 3/3] lightnvm: pblk: fix smeta write error path

2018-04-30 Thread Javier Gonzalez
> On 24 Apr 2018, at 07.45, Hans Holmberg > wrote: > > From: Hans Holmberg > > Smeta write errors were previously ignored. Skip these > lines instead and throw them back on the free > list, so the chunks will go through a reset cycle > before we attempt to use the line again. > >

Re: [PATCH v2 2/3] lightnvm: pblk: garbage collect lines with failed writes

2018-04-30 Thread Javier Gonzalez
> On 30 Apr 2018, at 11.14, Javier Gonzalez wrote: > >> On 24 Apr 2018, at 07.45, Hans Holmberg >> wrote: >> >> From: Hans Holmberg >> >> Write failures should not happen under normal circumstances, >> so in order to bring the chunk back int

Re: [PATCH v2 2/3] lightnvm: pblk: garbage collect lines with failed writes

2018-04-30 Thread Javier Gonzalez
> On 24 Apr 2018, at 07.45, Hans Holmberg > wrote: > > From: Hans Holmberg > > Write failures should not happen under normal circumstances, > so in order to bring the chunk back into a known state as soon > as possible, evacuate all

Re: [PATCH v2 2/3] lightnvm: pblk: garbage collect lines with failed writes

2018-04-30 Thread Javier Gonzalez
> On 24 Apr 2018, at 07.45, Hans Holmberg > wrote: > > From: Hans Holmberg > > Write failures should not happen under normal circumstances, > so in order to bring the chunk back into a known state as soon > as possible, evacuate all the valid data out of the line and let the > fw judge if the

Re: [PATCH v2 1/3] lightnvm: pblk: rework write error recovery path

2018-04-30 Thread Javier Gonzalez
> On 24 Apr 2018, at 07.45, Hans Holmberg > wrote: > > From: Hans Holmberg > > The write error recovery path is incomplete, so rework > the write error recovery handling to do resubmits directly > from the write buffer. > > When a

Re: [PATCH v2 1/3] lightnvm: pblk: rework write error recovery path

2018-04-30 Thread Javier Gonzalez
> On 24 Apr 2018, at 07.45, Hans Holmberg > wrote: > > From: Hans Holmberg > > The write error recovery path is incomplete, so rework > the write error recovery handling to do resubmits directly > from the write buffer. > > When a write error occurs, the remaining sectors in the chunk are >

Re: [PATCH v2 0/3] Rework write error handling in pblk

2018-04-30 Thread Javier Gonzalez
> On 28 Apr 2018, at 21.31, Matias Bjørling wrote: > > On 4/23/18 10:45 PM, Hans Holmberg wrote: >> From: Hans Holmberg >> This patch series fixes the(currently incomplete) write error handling >> in pblk by: >> * queuing and re-submitting failed

Re: [PATCH v2 0/3] Rework write error handling in pblk

2018-04-30 Thread Javier Gonzalez
> On 28 Apr 2018, at 21.31, Matias Bjørling wrote: > > On 4/23/18 10:45 PM, Hans Holmberg wrote: >> From: Hans Holmberg >> This patch series fixes the(currently incomplete) write error handling >> in pblk by: >> * queuing and re-submitting failed writes in the write buffer >> * evacuating

Re: [PATCH 3/3] lightnvm: pblk: fix smeta write error path

2018-04-20 Thread Javier Gonzalez
> On 19 Apr 2018, at 09.39, Hans Holmberg > wrote: > > From: Hans Holmberg > > Smeta write errors were previously ignored. Skip these > lines instead and throw them back on the free > list, so the chunks will go through a reset cycle

Re: [PATCH 3/3] lightnvm: pblk: fix smeta write error path

2018-04-20 Thread Javier Gonzalez
> On 19 Apr 2018, at 09.39, Hans Holmberg > wrote: > > From: Hans Holmberg > > Smeta write errors were previously ignored. Skip these > lines instead and throw them back on the free > list, so the chunks will go through a reset cycle > before we attempt to use the line again. > >

Re: [PATCH 2/3] lightnvm: pblk: garbage collect lines with failed writes

2018-04-20 Thread Javier Gonzalez
> On 19 Apr 2018, at 09.39, Hans Holmberg > wrote: > > From: Hans Holmberg > > Write failures should not happen under normal circumstances, > so in order to bring the chunk back into a known state as soon > as possible, evacuate all

Re: [PATCH 2/3] lightnvm: pblk: garbage collect lines with failed writes

2018-04-20 Thread Javier Gonzalez
> On 19 Apr 2018, at 09.39, Hans Holmberg > wrote: > > From: Hans Holmberg > > Write failures should not happen under normal circumstances, > so in order to bring the chunk back into a known state as soon > as possible, evacuate all the valid data out of the line and let the > fw judge if the

Re: [PATCH 1/3] lightnvm: pblk: rework write error recovery path

2018-04-20 Thread Javier Gonzalez
> On 19 Apr 2018, at 09.39, Hans Holmberg > wrote: > > From: Hans Holmberg > > The write error recovery path is incomplete, so rework > the write error recovery handling to do resubmits directly > from the write buffer. > > When a

Re: [PATCH 1/3] lightnvm: pblk: rework write error recovery path

2018-04-20 Thread Javier Gonzalez
> On 19 Apr 2018, at 09.39, Hans Holmberg > wrote: > > From: Hans Holmberg > > The write error recovery path is incomplete, so rework > the write error recovery handling to do resubmits directly > from the write buffer. > > When a write error occurs, the remaining sectors in the chunk are >

Re: [PATCH 07/11] lightnvm: pblk: remove unnecessary indirection

2018-04-18 Thread Javier Gonzalez
> On 17 Apr 2018, at 05.11, Matias Bjørling wrote: > > On 4/16/18 12:25 PM, Javier González wrote: >> Remove unnecessary indirection on the read path. > > Title and description are the same. Can you elaborate what changed > since pblk_submit_io now directly can be returned,

Re: [PATCH 07/11] lightnvm: pblk: remove unnecessary indirection

2018-04-18 Thread Javier Gonzalez
> On 17 Apr 2018, at 05.11, Matias Bjørling wrote: > > On 4/16/18 12:25 PM, Javier González wrote: >> Remove unnecessary indirection on the read path. > > Title and description are the same. Can you elaborate what changed > since pblk_submit_io now directly can be returned, and doesn't have >

Re: [PATCH] nvme: lightnvm: add granby support

2018-04-17 Thread Javier Gonzalez
> On 17 Apr 2018, at 03.55, Wei Xu wrote: > > Add a new lightnvm quirk to identify CNEX’s Granby controller. > > Signed-off-by: Wei Xu > --- > drivers/nvme/host/pci.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/nvme/host/pci.c

Re: [PATCH] nvme: lightnvm: add granby support

2018-04-17 Thread Javier Gonzalez
> On 17 Apr 2018, at 03.55, Wei Xu wrote: > > Add a new lightnvm quirk to identify CNEX’s Granby controller. > > Signed-off-by: Wei Xu > --- > drivers/nvme/host/pci.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c > index

Re: [PATCH 08/12] lightnvm: implement get log report chunk helpers

2018-03-21 Thread Javier Gonzalez
> On 21 Mar 2018, at 20.27, Matias Bjørling wrote: > >> On 03/21/2018 03:36 PM, Keith Busch wrote: >> On Wed, Mar 21, 2018 at 03:06:05AM -0700, Matias Bjørling wrote: outside of nvme core so that we can use it form lightnvm. Signed-off-by: Javier González

Re: [PATCH 08/12] lightnvm: implement get log report chunk helpers

2018-03-21 Thread Javier Gonzalez
> On 21 Mar 2018, at 20.27, Matias Bjørling wrote: > >> On 03/21/2018 03:36 PM, Keith Busch wrote: >> On Wed, Mar 21, 2018 at 03:06:05AM -0700, Matias Bjørling wrote: outside of nvme core so that we can use it form lightnvm. Signed-off-by: Javier González ---

Re: [PATCH 09/15] lightnvm: implement get log report chunk helpers

2018-03-01 Thread Javier Gonzalez
> On 1 Mar 2018, at 12.51, Matias Bjørling <m...@lightnvm.io> wrote: > > On 03/01/2018 12:02 PM, Javier Gonzalez wrote: >>> On 1 Mar 2018, at 11.40, Matias Bjørling <m...@lightnvm.io> wrote: >>> >>> On 02/28/2018 04:49 PM, Javier González wrot

Re: [PATCH 09/15] lightnvm: implement get log report chunk helpers

2018-03-01 Thread Javier Gonzalez
> On 1 Mar 2018, at 12.51, Matias Bjørling wrote: > > On 03/01/2018 12:02 PM, Javier Gonzalez wrote: >>> On 1 Mar 2018, at 11.40, Matias Bjørling wrote: >>> >>> On 02/28/2018 04:49 PM, Javier González wrote: >>>> The 2.0 spec provides a report

Re: [PATCH 09/15] lightnvm: implement get log report chunk helpers

2018-03-01 Thread Javier Gonzalez
> On 1 Mar 2018, at 11.40, Matias Bjørling wrote: > > On 02/28/2018 04:49 PM, Javier González wrote: >> The 2.0 spec provides a report chunk log page that can be retrieved >> using the stangard nvme get log page. This replaces the dedicated >> get/put bad block table in 1.2. >>

Re: [PATCH 09/15] lightnvm: implement get log report chunk helpers

2018-03-01 Thread Javier Gonzalez
> On 1 Mar 2018, at 11.40, Matias Bjørling wrote: > > On 02/28/2018 04:49 PM, Javier González wrote: >> The 2.0 spec provides a report chunk log page that can be retrieved >> using the stangard nvme get log page. This replaces the dedicated >> get/put bad block table in 1.2. >> This patch

Re: [PATCH] lightnvm: simplify geometry structure.

2018-02-27 Thread Javier Gonzalez
> On 27 Feb 2018, at 19.23, Matias Bjørling wrote: > > On 02/27/2018 04:57 PM, Javier González wrote: >> Currently, the device geometry is stored redundantly in the nvm_id and >> nvm_geo structures at a device level. Moreover, when instantiating >> targets on a specific number

Re: [PATCH] lightnvm: simplify geometry structure.

2018-02-27 Thread Javier Gonzalez
> On 27 Feb 2018, at 19.23, Matias Bjørling wrote: > > On 02/27/2018 04:57 PM, Javier González wrote: >> Currently, the device geometry is stored redundantly in the nvm_id and >> nvm_geo structures at a device level. Moreover, when instantiating >> targets on a specific number of LUNs, these

Re: [PATCH] lightnvm: simplify geometry structure.

2018-02-27 Thread Javier Gonzalez
> On 27 Feb 2018, at 16.57, Javier González wrote: > > Currently, the device geometry is stored redundantly in the nvm_id and > nvm_geo structures at a device level. Moreover, when instantiating > targets on a specific number of LUNs, these structures are replicated > and

Re: [PATCH] lightnvm: simplify geometry structure.

2018-02-27 Thread Javier Gonzalez
> On 27 Feb 2018, at 16.57, Javier González wrote: > > Currently, the device geometry is stored redundantly in the nvm_id and > nvm_geo structures at a device level. Moreover, when instantiating > targets on a specific number of LUNs, these structures are replicated > and manually modified to

Re: [PATCH V3 00/19] lightnvm: pblk: implement 2.0 support

2018-02-26 Thread Javier Gonzalez
> On 26 Feb 2018, at 19.24, Matias Bjørling <m...@lightnvm.io> wrote: > > On 02/26/2018 07:21 PM, Javier Gonzalez wrote: >>> On 26 Feb 2018, at 19.19, Matias Bjørling <m...@lightnvm.io> wrote: >>> >>> On 02/26/2018 02:16 PM, Javier González w

Re: [PATCH V3 00/19] lightnvm: pblk: implement 2.0 support

2018-02-26 Thread Javier Gonzalez
> On 26 Feb 2018, at 19.24, Matias Bjørling wrote: > > On 02/26/2018 07:21 PM, Javier Gonzalez wrote: >>> On 26 Feb 2018, at 19.19, Matias Bjørling wrote: >>> >>> On 02/26/2018 02:16 PM, Javier González wrote: >>>> # Changes since V2: >>&g

Re: [PATCH V3 00/19] lightnvm: pblk: implement 2.0 support

2018-02-26 Thread Javier Gonzalez
> On 26 Feb 2018, at 19.19, Matias Bjørling wrote: > > On 02/26/2018 02:16 PM, Javier González wrote: >> # Changes since V2: >> Apply Matias' feedback: >> - Remove generic nvm_id identify structure. >> - Do not remap capabilities (cap) to media and controlled capabilities >>

Re: [PATCH] lightnvm: pblk: remove unused variable

2018-02-26 Thread Javier Gonzalez
> On 26 Feb 2018, at 19.20, Matias Bjørling wrote: > > On 02/26/2018 02:18 PM, Javier González wrote: >> Remove unused variable after a previous cleanup (a8112b631adb) >> Signed-off-by: Javier González >> --- >> drivers/lightnvm/pblk-core.c | 3 --- >> 1

Re: [PATCH V3 00/19] lightnvm: pblk: implement 2.0 support

2018-02-26 Thread Javier Gonzalez
> On 26 Feb 2018, at 19.19, Matias Bjørling wrote: > > On 02/26/2018 02:16 PM, Javier González wrote: >> # Changes since V2: >> Apply Matias' feedback: >> - Remove generic nvm_id identify structure. >> - Do not remap capabilities (cap) to media and controlled capabilities >>(mccap).

Re: [PATCH] lightnvm: pblk: remove unused variable

2018-02-26 Thread Javier Gonzalez
> On 26 Feb 2018, at 19.20, Matias Bjørling wrote: > > On 02/26/2018 02:18 PM, Javier González wrote: >> Remove unused variable after a previous cleanup (a8112b631adb) >> Signed-off-by: Javier González >> --- >> drivers/lightnvm/pblk-core.c | 3 --- >> 1 file changed, 3 deletions(-) >> diff

Re: [PATCH 1/1] nvme: implement log page low/high offset and dwords

2018-02-26 Thread Javier Gonzalez
> On 13 Feb 2018, at 13.49, Matias Bjørling wrote: > > NVMe 1.2.1 extends the get log page interface to include 64 bit > offset and increases the number of dwords to 32 bits. Implement > for future use. > > Signed-off-by: Matias Bjørling > --- >

Re: [PATCH 1/1] nvme: implement log page low/high offset and dwords

2018-02-26 Thread Javier Gonzalez
> On 13 Feb 2018, at 13.49, Matias Bjørling wrote: > > NVMe 1.2.1 extends the get log page interface to include 64 bit > offset and increases the number of dwords to 32 bits. Implement > for future use. > > Signed-off-by: Matias Bjørling > --- > drivers/nvme/host/core.c | 36

Re: [PATCH 01/20] lightnvm: simplify geometry structure.

2018-02-22 Thread Javier Gonzalez
> On 22 Feb 2018, at 13.22, Matias Bjørling <m...@lightnvm.io> wrote: > > On 02/22/2018 08:44 AM, Javier Gonzalez wrote: >>> On 22 Feb 2018, at 08.25, Matias Bjørling <m...@lightnvm.io> wrote: >>> >>> On 02/21/2018 10:26 AM, Javier González wrot

Re: [PATCH 01/20] lightnvm: simplify geometry structure.

2018-02-22 Thread Javier Gonzalez
> On 22 Feb 2018, at 13.22, Matias Bjørling wrote: > > On 02/22/2018 08:44 AM, Javier Gonzalez wrote: >>> On 22 Feb 2018, at 08.25, Matias Bjørling wrote: >>> >>> On 02/21/2018 10:26 AM, Javier González wrote: >>>> Currently, the dev

Re: [PATCH 03/20] lightnvm: fix capabilities for 2.0 sysfs

2018-02-22 Thread Javier Gonzalez
> On 22 Feb 2018, at 12.10, Matias Bjørling <m...@lightnvm.io> wrote: > > On 02/22/2018 11:25 AM, Javier Gonzalez wrote: >>> On 22 Feb 2018, at 10.39, Matias Bjørling <m...@lightnvm.io> wrote: >>> >>> On 02/22/2018 08:47 AM, Javier Gonzalez wrote:

Re: [PATCH 03/20] lightnvm: fix capabilities for 2.0 sysfs

2018-02-22 Thread Javier Gonzalez
> On 22 Feb 2018, at 12.10, Matias Bjørling wrote: > > On 02/22/2018 11:25 AM, Javier Gonzalez wrote: >>> On 22 Feb 2018, at 10.39, Matias Bjørling wrote: >>> >>> On 02/22/2018 08:47 AM, Javier Gonzalez wrote: >>>>> On 22 Feb 2018, at 08.28,

Re: [PATCH 03/20] lightnvm: fix capabilities for 2.0 sysfs

2018-02-22 Thread Javier Gonzalez
> On 22 Feb 2018, at 10.39, Matias Bjørling <m...@lightnvm.io> wrote: > > On 02/22/2018 08:47 AM, Javier Gonzalez wrote: >>> On 22 Feb 2018, at 08.28, Matias Bjørling <m...@lightnvm.io> wrote: >>> >>>> On 02/21/2018 10:26 AM, Javier Gonzále

Re: [PATCH 03/20] lightnvm: fix capabilities for 2.0 sysfs

2018-02-22 Thread Javier Gonzalez
> On 22 Feb 2018, at 10.39, Matias Bjørling wrote: > > On 02/22/2018 08:47 AM, Javier Gonzalez wrote: >>> On 22 Feb 2018, at 08.28, Matias Bjørling wrote: >>> >>>> On 02/21/2018 10:26 AM, Javier González wrote: >>>> Both 1.2 an

Re: [PATCH 08/20] lightnvm: complete geo structure with maxoc*

2018-02-22 Thread Javier Gonzalez
Javier > On 22 Feb 2018, at 11.00, Matias Bjørling <m...@lightnvm.io> wrote: > > On 02/22/2018 10:52 AM, Javier Gonzalez wrote: >>> On 22 Feb 2018, at 10.45, Matias Bjørling <m...@lightnvm.io> wrote: >>> >>> On 02/22/2018 08:55 AM, Javier Gonzal

Re: [PATCH 08/20] lightnvm: complete geo structure with maxoc*

2018-02-22 Thread Javier Gonzalez
Javier > On 22 Feb 2018, at 11.00, Matias Bjørling wrote: > > On 02/22/2018 10:52 AM, Javier Gonzalez wrote: >>> On 22 Feb 2018, at 10.45, Matias Bjørling wrote: >>> >>> On 02/22/2018 08:55 AM, Javier Gonzalez wrote: >>>>> On 22 Feb 2018, a

Re: [PATCH 08/20] lightnvm: complete geo structure with maxoc*

2018-02-22 Thread Javier Gonzalez
> On 22 Feb 2018, at 10.45, Matias Bjørling <m...@lightnvm.io> wrote: > > On 02/22/2018 08:55 AM, Javier Gonzalez wrote: >>> On 22 Feb 2018, at 08.45, Matias Bjørling <m...@lightnvm.io> wrote: >>> >>> On 02/21/2018 10:26 AM, Javier González wro

Re: [PATCH 08/20] lightnvm: complete geo structure with maxoc*

2018-02-22 Thread Javier Gonzalez
> On 22 Feb 2018, at 10.45, Matias Bjørling wrote: > > On 02/22/2018 08:55 AM, Javier Gonzalez wrote: >>> On 22 Feb 2018, at 08.45, Matias Bjørling wrote: >>> >>> On 02/21/2018 10:26 AM, Javier González wrote: >>>> Complete the generic geometry

Re: [PATCH 08/20] lightnvm: complete geo structure with maxoc*

2018-02-21 Thread Javier Gonzalez
> On 22 Feb 2018, at 08.45, Matias Bjørling wrote: > > On 02/21/2018 10:26 AM, Javier González wrote: >> Complete the generic geometry structure with the maxoc and maxocpu >> felds, present in the 2.0 spec. >> Signed-off-by: Javier González >> --- >>

Re: [PATCH 08/20] lightnvm: complete geo structure with maxoc*

2018-02-21 Thread Javier Gonzalez
> On 22 Feb 2018, at 08.45, Matias Bjørling wrote: > > On 02/21/2018 10:26 AM, Javier González wrote: >> Complete the generic geometry structure with the maxoc and maxocpu >> felds, present in the 2.0 spec. >> Signed-off-by: Javier González >> --- >> drivers/nvme/host/lightnvm.c | 4 >>

Re: [PATCH 03/20] lightnvm: fix capabilities for 2.0 sysfs

2018-02-21 Thread Javier Gonzalez
> On 22 Feb 2018, at 08.28, Matias Bjørling wrote: > > On 02/21/2018 10:26 AM, Javier González wrote: >> Both 1.2 and 2.0 specs define a field for media and controller >> capabilities. Also, 1.2 defines a separate field dedicated to device >> capabilities. >> In 2.0 sysfs, this

Re: [PATCH 03/20] lightnvm: fix capabilities for 2.0 sysfs

2018-02-21 Thread Javier Gonzalez
> On 22 Feb 2018, at 08.28, Matias Bjørling wrote: > > On 02/21/2018 10:26 AM, Javier González wrote: >> Both 1.2 and 2.0 specs define a field for media and controller >> capabilities. Also, 1.2 defines a separate field dedicated to device >> capabilities. >> In 2.0 sysfs, this values have been

Re: [PATCH 01/20] lightnvm: simplify geometry structure.

2018-02-21 Thread Javier Gonzalez
> On 22 Feb 2018, at 08.25, Matias Bjørling wrote: > > On 02/21/2018 10:26 AM, Javier González wrote: >> Currently, the device geometry is stored redundantly in the nvm_id and >> nvm_geo structures at a device level. Moreover, when instantiating >> targets on a specific number

Re: [PATCH 01/20] lightnvm: simplify geometry structure.

2018-02-21 Thread Javier Gonzalez
> On 22 Feb 2018, at 08.25, Matias Bjørling wrote: > > On 02/21/2018 10:26 AM, Javier González wrote: >> Currently, the device geometry is stored redundantly in the nvm_id and >> nvm_geo structures at a device level. Moreover, when instantiating >> targets on a specific number of LUNs, these

Re: [PATCH v2 0/6] lightnvm: base 2.0 implementation

2018-02-21 Thread Javier Gonzalez
> On 15 Feb 2018, at 14.11, Matias Bjørling wrote: > > A couple of patches for 2.0 support for the lightnvm subsystem. They > form the foundation for the integration. > > The first two patches is preparation for the 2.0 work. The third patch > implements the 2.0 data

Re: [PATCH v2 0/6] lightnvm: base 2.0 implementation

2018-02-21 Thread Javier Gonzalez
> On 15 Feb 2018, at 14.11, Matias Bjørling wrote: > > A couple of patches for 2.0 support for the lightnvm subsystem. They > form the foundation for the integration. > > The first two patches is preparation for the 2.0 work. The third patch > implements the 2.0 data structures, the geometry

Re: [PATCH v2 5/6] lightnvm: remove nvm_dev_ops->max_phys_sect

2018-02-19 Thread Javier Gonzalez
> On 19 Feb 2018, at 08.31, Matias Bjørling <m...@lightnvm.io> wrote: > > On 02/16/2018 07:48 AM, Javier Gonzalez wrote: >>> On 15 Feb 2018, at 05.11, Matias Bjørling <m...@lightnvm.io> wrote: >>> >>> The value of max_phys_sect is always stati

Re: [PATCH v2 5/6] lightnvm: remove nvm_dev_ops->max_phys_sect

2018-02-19 Thread Javier Gonzalez
> On 19 Feb 2018, at 08.31, Matias Bjørling wrote: > > On 02/16/2018 07:48 AM, Javier Gonzalez wrote: >>> On 15 Feb 2018, at 05.11, Matias Bjørling wrote: >>> >>> The value of max_phys_sect is always static. Instead of >>> defining it in the

Re: [PATCH v2 5/6] lightnvm: remove nvm_dev_ops->max_phys_sect

2018-02-15 Thread Javier Gonzalez
> On 15 Feb 2018, at 05.11, Matias Bjørling wrote: > > The value of max_phys_sect is always static. Instead of > defining it in the nvm_dev_ops structure, declare it as a global > value. > > Signed-off-by: Matias Bjørling > --- > drivers/lightnvm/core.c

Re: [PATCH v2 5/6] lightnvm: remove nvm_dev_ops->max_phys_sect

2018-02-15 Thread Javier Gonzalez
> On 15 Feb 2018, at 05.11, Matias Bjørling wrote: > > The value of max_phys_sect is always static. Instead of > defining it in the nvm_dev_ops structure, declare it as a global > value. > > Signed-off-by: Matias Bjørling > --- > drivers/lightnvm/core.c | 28

Re: [PATCH 2/8] lightnvm: show generic geometry in sysfs

2018-02-15 Thread Javier Gonzalez
> On 15 Feb 2018, at 02.20, Matias Bjørling wrote: > > On 02/13/2018 03:06 PM, Javier González wrote: >> From: Javier González >> Apart from showing the geometry returned by the different identify >> commands, provide the generic geometry too, as this is

Re: [PATCH 2/8] lightnvm: show generic geometry in sysfs

2018-02-15 Thread Javier Gonzalez
> On 15 Feb 2018, at 02.20, Matias Bjørling wrote: > > On 02/13/2018 03:06 PM, Javier González wrote: >> From: Javier González >> Apart from showing the geometry returned by the different identify >> commands, provide the generic geometry too, as this is the geometry that >> targets will use

Re: [PATCH 1/8] lightnvm: exposed generic geometry to targets

2018-02-15 Thread Javier Gonzalez
> On 15 Feb 2018, at 02.13, Matias Bjørling wrote: > >> On 02/13/2018 03:06 PM, Javier González wrote: >> With the inclusion of 2.0 support, we need a generic geometry that >> describes the OCSSD independently of the specification that it >> implements. Otherwise, geometry

Re: [PATCH 1/8] lightnvm: exposed generic geometry to targets

2018-02-15 Thread Javier Gonzalez
> On 15 Feb 2018, at 02.13, Matias Bjørling wrote: > >> On 02/13/2018 03:06 PM, Javier González wrote: >> With the inclusion of 2.0 support, we need a generic geometry that >> describes the OCSSD independently of the specification that it >> implements. Otherwise, geometry specific code is

Re: [PATCH V2 4/4] nvme: lightnvm: add late setup of block size and metadata

2018-02-12 Thread Javier Gonzalez
> On 9 Feb 2018, at 01.27, Matias Bjørling wrote: > > The nvme driver sets up the size of the nvme namespace in two steps. > First it initializes the device with standard logical block and > metadata sizes, and then sets the correct logical block and metadata > size. Due to

Re: [PATCH V2 4/4] nvme: lightnvm: add late setup of block size and metadata

2018-02-12 Thread Javier Gonzalez
> On 9 Feb 2018, at 01.27, Matias Bjørling wrote: > > The nvme driver sets up the size of the nvme namespace in two steps. > First it initializes the device with standard logical block and > metadata sizes, and then sets the correct logical block and metadata > size. Due to the OCSSD 2.0

Re: [PATCH 3/4] lightnvm: add 2.0 geometry identification

2018-02-08 Thread Javier Gonzalez
> On 5 Feb 2018, at 13.15, Matias Bjørling wrote: > > Implement the geometry data structures for 2.0 and enable a drive > to be identified as one, including exposing the appropriate 2.0 > sysfs entries. > > Signed-off-by: Matias Bjørling > --- >

Re: [PATCH 3/4] lightnvm: add 2.0 geometry identification

2018-02-08 Thread Javier Gonzalez
> On 5 Feb 2018, at 13.15, Matias Bjørling wrote: > > Implement the geometry data structures for 2.0 and enable a drive > to be identified as one, including exposing the appropriate 2.0 > sysfs entries. > > Signed-off-by: Matias Bjørling > --- > drivers/lightnvm/core.c | 2 +- >

Re: [PATCH 0/4] lightnvm: base 2.0 implementation

2018-02-08 Thread Javier Gonzalez
> On 5 Feb 2018, at 13.15, Matias Bjørling wrote: > > Hi, > > A couple of patches for 2.0 support for the lightnvm subsystem. They > form the basis for integrating 2.0 support. > > For the rest of the support, Javier has code that implements report > chunk and sets up the LBA

Re: [PATCH 0/4] lightnvm: base 2.0 implementation

2018-02-08 Thread Javier Gonzalez
> On 5 Feb 2018, at 13.15, Matias Bjørling wrote: > > Hi, > > A couple of patches for 2.0 support for the lightnvm subsystem. They > form the basis for integrating 2.0 support. > > For the rest of the support, Javier has code that implements report > chunk and sets up the LBA format data

Re: [PATCH 5/5] lightnvm: pblk: refactor bad block identification

2018-02-04 Thread Javier Gonzalez
> On 4 Feb 2018, at 13.55, Matias Bjørling <m...@lightnvm.io> wrote: > > On 02/04/2018 11:37 AM, Javier Gonzalez wrote: >>> On 31 Jan 2018, at 19.24, Matias Bjørling <m...@lightnvm.io> wrote: >>> >>> On 01/31/2018 10:13 AM, Javier Gonzalez wrote:

Re: [PATCH 5/5] lightnvm: pblk: refactor bad block identification

2018-02-04 Thread Javier Gonzalez
> On 4 Feb 2018, at 13.55, Matias Bjørling wrote: > > On 02/04/2018 11:37 AM, Javier Gonzalez wrote: >>> On 31 Jan 2018, at 19.24, Matias Bjørling wrote: >>> >>> On 01/31/2018 10:13 AM, Javier Gonzalez wrote: >>>>> On 31 Jan 2018, at 16.51, M

Re: [PATCH 5/5] lightnvm: pblk: refactor bad block identification

2018-02-04 Thread Javier Gonzalez
> On 31 Jan 2018, at 19.24, Matias Bjørling <m...@lightnvm.io> wrote: > > On 01/31/2018 10:13 AM, Javier Gonzalez wrote: >>> On 31 Jan 2018, at 16.51, Matias Bjørling <m...@lightnvm.io> wrote: >>> >> I have a patches abstracting this, which I thin

  1   2   >