Re: [PATCH v2 5/6] lightnvm: remove nvm_dev_ops->max_phys_sect
> 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
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
> 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
