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 nvm_dev_ops structure, declare it as a global
>>> value.
>>> 
>>> Signed-off-by: Matias Bjørling 
>>> ---
>>> drivers/lightnvm/core.c  | 28 +++-
>>> drivers/lightnvm/pblk-init.c |  9 -
>>> drivers/lightnvm/pblk-recovery.c |  8 ++--
>>> drivers/nvme/host/lightnvm.c |  5 +
>>> include/linux/lightnvm.h |  5 ++---
>>> 5 files changed, 16 insertions(+), 39 deletions(-)
>> The patch looks good, but I have a question. If a target implements the
>> scalar interface, then it will not be limited to 64 lbas/ppas and it
>> will not make sense to split the bio base don this value. In fact, it
>> looks like in time, we will move to a scalar interface in the 2.0 path
>> to align with the zoned interface, so this value will be dependent on
>> whether the target is using the scalar or vector interface.
> 
> Both read/write and vector interface will coexist. I am only removing
> what is hardwired into the specification.
> 
> The read/write interface has always been able issue more than 64 LBAs,
> it is instead limited by what the hardware reports its max transfer
> size to be.
> 

Exactly. I was thinking of a similar mechanism for the vector interface
to simplify integration with the scalar interface and avoid having an
if/else for what we now call max_phys_sect.

I guess we can wait and see what the code looks like when we adapt pblk.

Reviewed-by: Javier González 

Javier


signature.asc
Description: Message signed with OpenPGP


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

2018-02-18 Thread Matias Bjørling

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 nvm_dev_ops structure, declare it as a global
value.

Signed-off-by: Matias Bjørling 
---
drivers/lightnvm/core.c  | 28 +++-
drivers/lightnvm/pblk-init.c |  9 -
drivers/lightnvm/pblk-recovery.c |  8 ++--
drivers/nvme/host/lightnvm.c |  5 +
include/linux/lightnvm.h |  5 ++---
5 files changed, 16 insertions(+), 39 deletions(-)



The patch looks good, but I have a question. If a target implements the
scalar interface, then it will not be limited to 64 lbas/ppas and it
will not make sense to split the bio base don this value. In fact, it
looks like in time, we will move to a scalar interface in the 2.0 path
to align with the zoned interface, so this value will be dependent on
whether the target is using the scalar or vector interface.



Both read/write and vector interface will coexist. I am only removing 
what is hardwired into the specification.


The read/write interface has always been able issue more than 64 LBAs, 
it is instead limited by what the hardware reports its max transfer size 
to be.


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 +++-
> drivers/lightnvm/pblk-init.c |  9 -
> drivers/lightnvm/pblk-recovery.c |  8 ++--
> drivers/nvme/host/lightnvm.c |  5 +
> include/linux/lightnvm.h |  5 ++---
> 5 files changed, 16 insertions(+), 39 deletions(-)
> 

The patch looks good, but I have a question. If a target implements the
scalar interface, then it will not be limited to 64 lbas/ppas and it
will not make sense to split the bio base don this value. In fact, it
looks like in time, we will move to a scalar interface in the 2.0 path
to align with the zoned interface, so this value will be dependent on
whether the target is using the scalar or vector interface.

Javier


signature.asc
Description: Message signed with OpenPGP