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

[Javier Gonzalez]

> On 4 Feb 2018, at 13.55, Matias BjÃrling <mb@xxxxxxxxxxx> wrote:
> 
> On 02/04/2018 11:37 AM, Javier Gonzalez wrote:
>>> On 31 Jan 2018, at 19.24, Matias BjÃrling <mb@xxxxxxxxxxx> wrote:
>>> 
>>> On 01/31/2018 10:13 AM, Javier Gonzalez wrote:
>>>>> On 31 Jan 2018, at 16.51, Matias BjÃrling <mb@xxxxxxxxxxx> wrote:
>>>>> 
>>>> I have a patches abstracting this, which I think it makes it cleaner. I can push it next week for review. Iâm traveling this week. (If you want to get a glimpse I can point you to the code).
>>> 
>>> Yes, please do. Thanks
>> This is the release candidate for 2.0 support based on 4.17. I'll rebase
>> on top of you 2.0 support. We'll see if all changes make it to 4.17
>> then.
>> https://github.com/OpenChannelSSD/linux/tree/for-4.17/spec20
>> Javier
> 
> Great. I look forward to be patches being cleaned up and posted. I do see some nitpicks here and there, which we properly can take a couple of stabs at.

Sure. This is still in development; just wanted to point to the abstractions Iâm thinking of so that we donât do the same work twice. 

Iâll wait for posting until you do the 2.0 identify, since the old version is implemented on the first patch of this series. 

> One think that generally stands out to me is the "if 1.2 support", else, ... statements. These could be structured better by having dedicated setup functions for 1.2 and 2.0.

We have this construction both in pblk and in core for address translation. Note that we need to have them separated to support multi instance and keep channels decoupled from each instance. 

I assume 2 if...then is cheaper than doing 2 de-references to function pointers. This is the way it is done on legacy paths in other places (e.g., non mq scsi), but I can look into how pointer functions would look like and measure the performance impact. 

Javier