Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751359AbdHaDGK (ORCPT ); Wed, 30 Aug 2017 23:06:10 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:21086 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750802AbdHaDGJ (ORCPT ); Wed, 30 Aug 2017 23:06:09 -0400 To: Suganath Prabu Subramani Cc: "Martin K. Petersen" , linux-scsi@vger.kernel.org, Sathya Prakash , Kashyap Desai , linux-kernel@vger.kernel.org, Chaitra Basappa , Sreekanth Reddy , linux-nvme@lists.infradead.org Subject: Re: [PATCH v4 00/14] mpt3sas driver NVMe support: From: "Martin K. Petersen" Organization: Oracle Corporation References: <1503322344-5900-1-git-send-email-suganath-prabu.subramani@broadcom.com> Date: Wed, 30 Aug 2017 23:05:37 -0400 In-Reply-To: (Suganath Prabu Subramani's message of "Wed, 30 Aug 2017 18:00:26 +0530") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Source-IP: aserv0021.oracle.com [141.146.126.233] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1565 Lines: 39 Hi Suganath, > Theoretically we want to use h/w capability (to translate IEEE to PRP) > for smaller IO size to leverage h/w capability. Nobody says we have to use the capability just because the hardware has it. Unlike some other operating systems, Linux will only submit I/Os to the driver that conform to the reported underlying constraints of the hardware. I fail to understand how letting the HBA firmware translate an SGL to a PRP for a subset of I/Os could do anything but add latency. Plus complexity in the hot path of the driver. > - If the unmap translation in firmware is slow, why don't you translate > WRITE SAME/w UNMAP set to DSM DEALLOCATE without requiring > applications to do encapsulated passthrough? > => As of now, current FW supports UNMAP command but not WRITE_SAME for > NVME drive. We did some experiment to convert UMAP command in driver, > but that is not really giving any performance improvement. It is imperative that the common use case, Linux' discard infrastructure, is working correctly and is as performant as any application-driven passthrough workaround. Unlike SCSI-to-SATA translation you have the benefit of a 1:1 mapping between UNMAP and DEALLOCATE. I'm not even sure why there would be a significant performance penalty in the firmware? > We would like to continue with UNMAP (and all other non-read/write > commands) to be handled in FW. And yet patch 4 circumvents that statement by adding support for encapsulated commands to bypass the FW translation... -- Martin K. Petersen Oracle Linux Engineering