Re: [PATCH] lightnvm: move device L2P detection to core

From: Javier Gonzalez <javier@cnexlabs.com>
To: "Matias Bjørling" <mb@lightnvm.io>
Cc: "Konopko, Igor J" <igor.j.konopko@intel.com>,
	"marcin.dziegielewski@intel.com" <marcin.dziegielewski@intel.com>,
	Hans Holmberg <hans.holmberg@cnexlabs.com>,
	Heiner Litz <hlitz@ucsc.edu>,
	Young Tack Tack Jin <youngtack.jin@circuitblvd.com>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] lightnvm: move device L2P detection to core
Date: Fri, 3 Aug 2018 12:55:46 +0000	[thread overview]
Message-ID: <B2E9F490-32FD-49C5-906D-994762E7191D@cnexlabs.com> (raw)
In-Reply-To: <56562d7c-8deb-4597-4274-5a55ec9327f7@lightnvm.io>

[-- Attachment #1: Type: text/plain, Size: 2270 bytes --]

> On 3 Aug 2018, at 14.43, Matias Bjørling <mb@lightnvm.io> wrote:
> 
> On 08/03/2018 02:40 PM, Javier Gonzalez wrote:
>>> On 3 Aug 2018, at 14.37, Matias Bjørling <mb@lightnvm.io> wrote:
>>> 
>>> On 08/03/2018 02:16 PM, Javier Gonzalez wrote:
>>>>> On 3 Aug 2018, at 10.54, Matias Bjørling <mb@lightnvm.io> wrote:
>>>>> 
>>>>> A 1.2 device is able to manage the logical to physical mapping
>>>>> table internally or leave it to the host.
>>>>> 
>>>>> A target only supports one of those approaches, and therefore must
>>>>> check on initialization. Move this check to core to avoid each target
>>>>> implement the check.
>>>>> 
>>>>> Signed-off-by: Matias Bjørling <mb@lightnvm.io>
>>>>> ---
>>>> I see where you want to go with these changes, but the way targets are
>>>> layered on top of the LightNVM subsystem does not align with it.
>>>> LightNVM can support different OCSSD versions and capabilities, but that
>>>> does not mean that a target (e.g., pblk) does. The way I see it, core
>>>> should only check for (i) the drive to expose itself in a known revision
>>>> and (ii) the reported structures to be consistent. However, specific
>>>> functionality is not for core to check upo.
>>> 
>>> Why try to initialize a target, if we already know that it is incompatible?
>> Yes, that is my point. But the one who knows if the targets supports
>> something or not is the target, not the subsystem. Here, you are making
>> an assumption knowing the pblk requires the L2P on the host, but that
>> could change in the future...
> 
> I don't believe it can. It is not supported by the 2.0 specification.
> 1.2 is legacy.
> 

Ja... We both know that people is using 1.2 variants out there...

> I understand this from the perspective when checking for un-even
> configurations using the geometry. But this is a spec incompatibility,
> which I don't think the target should care about.

I see the point of not having this check in pblk since we know that we
are moving towards 2.0 and leaving 1.2 as legacy/not-upstream. But does
it really make sense to fail LightNVM on a 1.2 capability that is spec.
compliant? For all we know people could have this and use it from user
space or through an internal target.

Javier

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]