Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966145AbdIYUWy (ORCPT ); Mon, 25 Sep 2017 16:22:54 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:38516 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934287AbdIYUWw (ORCPT ); Mon, 25 Sep 2017 16:22:52 -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, Jayant Daftardar 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: Mon, 25 Sep 2017 16:22:21 -0400 In-Reply-To: (Suganath Prabu Subramani's message of "Mon, 18 Sep 2017 16:09:09 +0530") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Source-IP: userv0022.oracle.com [156.151.31.74] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1391 Lines: 32 Hi Suganath, > Also, Making all PRP buffer may or may not need FW changes (assuming > it is possible.), we may end up into multiple FW version check. I don't understand how submitting an I/O that is guaranteed to honor the constraints of the target NVMe drive could possibly cause problems for the controller firmware. Quite the contrary, it's the best case scenario. > Since this is main IO path and current driver is following H/W > limitation, we should avoid any changes in this area until and unless > change is universal acceptable in FW (for all type of work load). This is why you need to involve the Linux community early in the design process and not when your implementation is complete. We could have told you right away what the correct approach would be for your Linux driver. And that said approach works for products from other vendors so we see no compelling reason to deviate from it. As evidenced by Broadcom disowning the legacy mpt and megaraid drivers, I will be stuck maintaining this mpt3sas code for a decade or more. Long after Broadcom has ended official support and moved on to different ASICs and programming interfaces. Consequently, I am very heavily biased towards solutions that leverage the shared interfaces provided by the kernel and that don't have special cases and workarounds inside the driver. -- Martin K. Petersen Oracle Linux Engineering