[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <918E7340-05D7-4E2F-BC43-2B81D435C3C6@cnexlabs.com>
Date: Fri, 16 Feb 2018 06:48:23 +0000
From: Javier Gonzalez <javier@...xlabs.com>
To: Matias Bjørling <mb@...htnvm.io>
CC: "linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-nvme@...ts.infradead.org" <linux-nvme@...ts.infradead.org>
Subject: Re: [PATCH v2 5/6] lightnvm: remove nvm_dev_ops->max_phys_sect
> On 15 Feb 2018, at 05.11, Matias Bjørling <mb@...htnvm.io> 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 <mb@...htnvm.io>
> ---
> 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
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists