From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757879AbbJ2RVL (ORCPT ); Thu, 29 Oct 2015 13:21:11 -0400 Received: from mga14.intel.com ([192.55.52.115]:35559 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757446AbbJ2RVJ (ORCPT ); Thu, 29 Oct 2015 13:21:09 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,215,1444719600"; d="scan'208";a="838167699" Date: Thu, 29 Oct 2015 17:20:43 +0000 From: "Busch, Keith" To: Nishanth Aravamudan Cc: Christoph Hellwig , aik@ozlabs.ru, linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org, paulus@samba.org, sparclinux@vger.kernel.org, willy@linux.intel.com, linuxppc-dev@lists.ozlabs.org, David Miller , david@gibson.dropbear.id.au Subject: Re: [PATCH 0/5 v3] Fix NVMe driver support on Power with 32-bit DMA Message-ID: <20151029172043.GA8343@localhost.localdomain> References: <20151026.182746.1323901353520152838.davem@davemloft.net> <20151027222010.GD7716@linux.vnet.ibm.com> <20151027223643.GA25332@localhost.localdomain> <20151027.175443.140992924519172506.davem@davemloft.net> <20151028135922.GA27909@localhost.localdomain> <20151029115536.GA28090@infradead.org> <20151029155701.GJ7716@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151029155701.GJ7716@linux.vnet.ibm.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 29, 2015 at 08:57:01AM -0700, Nishanth Aravamudan wrote: > On 29.10.2015 [04:55:36 -0700], Christoph Hellwig wrote: > > We had a quick cht about this issue and I think we simply should > > default to a NVMe controler page size of 4k everywhere as that's the > > safe default. This is also what we do for RDMA Memory reigstrations and > > it works fine there for SRP and iSER. > > So, would that imply changing just the NVMe driver code rather than > adding the dma_page_shift API at all? What about > architectures that can support the larger page sizes? There is an > implied performance impact, at least, of shifting the IO size down. It is the safe option, but you're right that it might have a measurable performance impact (can you run an experiment?). Maybe we should just change the driver to always use MPSMIN for the moment in the interest of time, and you can flush out the new API before the next merge window.