Received: by 10.223.185.116 with SMTP id b49csp3448938wrg; Sun, 18 Feb 2018 23:32:31 -0800 (PST) X-Google-Smtp-Source: AH8x225eQV3GxmTuM/orbZZmpSQnJAseqFk3d0jLSUGWyRC97eEPgo184WD8lEwS+qlhHUayAWDd X-Received: by 2002:a17:902:42e:: with SMTP id 43-v6mr13796045ple.186.1519025551022; Sun, 18 Feb 2018 23:32:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519025550; cv=none; d=google.com; s=arc-20160816; b=UrP9X85s6/kIHXWK39Vdx2FdMp6Z7gZGIoZoPXZcHHhcn1IfMSovyDzq69iQppfkCV hb9LZf7Rsvo2GWEkxml9lTndAG6sCi5UfbQkz7tWN+FdSRPosizgfgJQiacR+FxyuD1j a80Z3+2Tt20ZjcDiCXCJR0RdRrf6Fbh6t4LZxrdpGj0cw3WR8huaUnm1thX5D08Z2h9o WSW54OhSEAPpNncfNi41m0lCyVMUafa+MO09jaNTHpCiWlXIxPOes4hLRRjW5oyn9fuH +xFOpUiIXRDoxF/vOhvcJFe9t0U80js2xahYFvO/tpJm1D5J9Tk6RHUsnOAnJRBCM9W7 tO2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=gN/PS0Trmk7+ELbD7jNsMhgQDTAX+tFVVLo0vJyL5zs=; b=EqHt+cufDvscf1BNhb4TOgyGdJXBCmvoUZWihkZb1oswvSi4TSDpuXou0MafwfVqSi AZP1bMNBsntebKfngr6mjbPmckLj53kRYS5DZFvC7vgNriVKSvQwdBf1KlS6bU9Bs1z5 ldAaBADMIbtRCo3lLb6c0OuLNI8OR5J1/cf3oZJSBfrBnnA+uJ+3DiwteM+SsJH95wlw lXvwZDPonToxqzooK4FSp0JLhmr9fYFskJcw2GKmSXPF/UOOKOiWJ072bBLh8LHF/qou Eiqn5vs1/u9OdYVhpj6BPkG3/k51lS5rfqmJlQDdlPmKmh/3V8NHWMNjdgbuYf+rsFFU ig/w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@lightnvm-io.20150623.gappssmtp.com header.s=20150623 header.b=Oa+JcGYp; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x5-v6si5364510pln.351.2018.02.18.23.32.16; Sun, 18 Feb 2018 23:32:30 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@lightnvm-io.20150623.gappssmtp.com header.s=20150623 header.b=Oa+JcGYp; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751687AbeBSHbg (ORCPT + 99 others); Mon, 19 Feb 2018 02:31:36 -0500 Received: from mail-lf0-f67.google.com ([209.85.215.67]:34897 "EHLO mail-lf0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751467AbeBSHbe (ORCPT ); Mon, 19 Feb 2018 02:31:34 -0500 Received: by mail-lf0-f67.google.com with SMTP id 70so5714597lfw.2 for ; Sun, 18 Feb 2018 23:31:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lightnvm-io.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=gN/PS0Trmk7+ELbD7jNsMhgQDTAX+tFVVLo0vJyL5zs=; b=Oa+JcGYpZFQSgjB4bmHt1RfgaQ+BV6tpTOLTTDFsWTBuqohUWCk5B4zPqP3tjr/5of vpSDdB2hNfIxP3Gu1LWQe/oDM/fX3xeNh+sNq4QQE59gN7QofIRU2M2HAGtr01es27WX e5o/4YLQr7A+U4bt1pNVSjE1mXaslCxM+buKPgcTw7SYbXg/rec4HeMmddoQv+JUFuqq FHWcGPQctKY8lytS1E/MFreIvHZczho7iLBGLr97IfJvFOQIWILg7VfOLrLuBClV8erg E2nWx/b2r5jHsPXPSHA4vNaol72TZ2ERo0oFRk1Dif05Cbg76CKgpcEhKe4DSzPqLwXd fDow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=gN/PS0Trmk7+ELbD7jNsMhgQDTAX+tFVVLo0vJyL5zs=; b=NLYdf00fuAGPhUJ9KwYv+13rVL6mHDv6S4mOlj+K0yXgMtlFKB2mSHLgSRsvj5wk1G Hyq74AW9UFSgtlMDfN59kPNLR33i0URo1vOWLHgccKpJ0Eix0G2Hd86/FwlBeUruNzzj n5Cpua0bC9C/ayfcpgXhWAzHST3TdRGS9UhGEl3OPOQFrarBy3+VPK9PPRK8l84dPQv/ oRktnHCrQEIqfQ/6f9oj+NHTlSPBCwAHU3JL98oCZhI3B3HgJRw3hCQV8QRCmQ0tmw3o C3Ee8M3isBVnyaHuIYrR1SKXeVaUZOs1ZNee7mkj72NhmpdKbO78Z7ZJUhdVBNbbQRzH 8oHQ== X-Gm-Message-State: APf1xPCvXBN6oYbH8jfFocD/L16NKY1XDPzy8MWsHvVqIbHDtmrNtwuy jC7YIen8QyiGTp4nu3KfZhO7eA== X-Received: by 10.46.51.6 with SMTP id d6mr8445635ljc.57.1519025493388; Sun, 18 Feb 2018 23:31:33 -0800 (PST) Received: from [192.168.0.10] (x1-6-a4-08-f5-18-3c-3a.cpe.webspeed.dk. [188.176.29.198]) by smtp.googlemail.com with ESMTPSA id h16sm547810lji.72.2018.02.18.23.31.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Feb 2018 23:31:32 -0800 (PST) Subject: Re: [PATCH v2 5/6] lightnvm: remove nvm_dev_ops->max_phys_sect To: Javier Gonzalez Cc: "linux-block@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-nvme@lists.infradead.org" References: <20180215131200.3354-1-mb@lightnvm.io> <20180215131200.3354-6-mb@lightnvm.io> <918E7340-05D7-4E2F-BC43-2B81D435C3C6@cnexlabs.com> From: =?UTF-8?Q?Matias_Bj=c3=b8rling?= Message-ID: <899e5ed5-4bf7-666a-d756-d86420cf9c9e@lightnvm.io> Date: Mon, 19 Feb 2018 08:31:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <918E7340-05D7-4E2F-BC43-2B81D435C3C6@cnexlabs.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.