From: "Martin K. Petersen" <martin.petersen@oracle.com> To: Suganath Prabu Subramani <suganath-prabu.subramani@broadcom.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com>, linux-scsi@vger.kernel.org, Sathya Prakash <Sathya.Prakash@broadcom.com>, Kashyap Desai <kashyap.desai@broadcom.com>, linux-kernel@vger.kernel.org, Chaitra Basappa <chaitra.basappa@broadcom.com>, Sreekanth Reddy <sreekanth.reddy@broadcom.com>, linux-nvme@lists.infradead.org, Jayant Daftardar <jayant.daftardar@broadcom.com> Subject: Re: [PATCH v4 00/14] mpt3sas driver NVMe support: Date: Mon, 25 Sep 2017 16:22:21 -0400 [thread overview] Message-ID: <yq1o9pyfs02.fsf@oracle.com> (raw) In-Reply-To: <CA+RiK65GPnfqpQAuUWEs_NdW9crumkGparCqynN_dBti8BPXqQ@mail.gmail.com> (Suganath Prabu Subramani's message of "Mon, 18 Sep 2017 16:09:09 +0530") 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
WARNING: multiple messages have this Message-ID (diff)
From: martin.petersen@oracle.com (Martin K. Petersen) Subject: [PATCH v4 00/14] mpt3sas driver NVMe support: Date: Mon, 25 Sep 2017 16:22:21 -0400 [thread overview] Message-ID: <yq1o9pyfs02.fsf@oracle.com> (raw) In-Reply-To: <CA+RiK65GPnfqpQAuUWEs_NdW9crumkGparCqynN_dBti8BPXqQ@mail.gmail.com> (Suganath Prabu Subramani's message of "Mon, 18 Sep 2017 16:09:09 +0530") 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
next prev parent reply other threads:[~2017-09-25 20:22 UTC|newest] Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-08-21 13:32 [PATCH v4 00/14] mpt3sas driver NVMe support: Suganath Prabu S 2017-08-21 13:32 ` Suganath Prabu S 2017-08-21 13:32 ` [PATCH v4 01/14] mpt3sas: Update MPI Header Suganath Prabu S 2017-08-21 13:32 ` Suganath Prabu S 2017-08-21 13:32 ` [PATCH v4 02/14] mpt3sas: Add nvme device support in slave alloc, target alloc and probe Suganath Prabu S 2017-08-21 13:32 ` Suganath Prabu S 2017-08-21 13:32 ` [PATCH v4 03/14] mpt3sas: SGL to PRP Translation for I/Os to NVMe devices Suganath Prabu S 2017-08-21 13:32 ` Suganath Prabu S 2017-08-21 13:32 ` [PATCH v4 04/14] mpt3sas: Added support for nvme encapsulated request message Suganath Prabu S 2017-08-21 13:32 ` Suganath Prabu S 2017-08-21 13:32 ` [PATCH v4 05/14] mpt3sas: API 's to support NVMe drive addition to SML Suganath Prabu S 2017-08-21 13:32 ` Suganath Prabu S 2017-08-21 13:32 ` [PATCH v4 06/14] mpt3sas: API's to remove nvme drive from sml Suganath Prabu S 2017-08-21 13:32 ` Suganath Prabu S 2017-08-21 13:32 ` [PATCH v4 07/14] mpt3sas: Handle NVMe PCIe device related events generated from firmware Suganath Prabu S 2017-08-21 13:32 ` Suganath Prabu S 2017-08-21 13:32 ` [PATCH v4 08/14] mpt3sas: Set NVMe device queue depth as 128 Suganath Prabu S 2017-08-21 13:32 ` Suganath Prabu S 2017-08-21 13:32 ` [PATCH v4 09/14] mpt3sas: scan and add nvme device after controller reset Suganath Prabu S 2017-08-21 13:32 ` Suganath Prabu S 2017-08-21 13:32 ` [PATCH v4 10/14] mpt3as: Add-Task-management-debug-info-for-NVMe-drives Suganath Prabu S 2017-08-21 13:32 ` Suganath Prabu S 2017-08-21 13:32 ` [PATCH v4 11/14] mpt3sas: NVMe drive support for BTDHMAPPING ioctl command and log info Suganath Prabu S 2017-08-21 13:32 ` Suganath Prabu S 2017-08-21 13:32 ` [PATCH v4 12/14] mpt3sas: Fix nvme drives checking for tlr Suganath Prabu S 2017-08-21 13:32 ` Suganath Prabu S 2017-08-21 13:32 ` [PATCH v4 13/14] mpt3sas: Update mpt3sas driver version Suganath Prabu S 2017-08-21 13:32 ` Suganath Prabu S 2017-08-21 13:32 ` [PATCH v4 14/14] mpt3sas: Fix sparse warning Suganath Prabu S 2017-08-21 13:32 ` Suganath Prabu S 2017-08-23 2:18 ` [PATCH v4 00/14] mpt3sas driver NVMe support: Martin K. Petersen 2017-08-23 2:18 ` Martin K. Petersen 2017-08-30 12:30 ` Suganath Prabu Subramani 2017-08-30 12:30 ` Suganath Prabu Subramani 2017-08-31 3:05 ` Martin K. Petersen 2017-08-31 3:05 ` Martin K. Petersen 2017-08-31 4:58 ` Suganath Prabu Subramani 2017-08-31 4:58 ` Suganath Prabu Subramani 2017-09-01 3:22 ` Martin K. Petersen 2017-09-01 3:22 ` Martin K. Petersen 2017-09-01 8:39 ` Suganath Prabu Subramani 2017-09-01 8:39 ` Suganath Prabu Subramani 2017-09-13 7:15 ` Suganath Prabu Subramani 2017-09-13 7:15 ` Suganath Prabu Subramani 2017-09-15 1:07 ` Martin K. Petersen 2017-09-15 1:07 ` Martin K. Petersen 2017-09-18 10:39 ` Suganath Prabu Subramani 2017-09-18 10:39 ` Suganath Prabu Subramani 2017-09-25 20:22 ` Martin K. Petersen [this message] 2017-09-25 20:22 ` Martin K. Petersen
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=yq1o9pyfs02.fsf@oracle.com \ --to=martin.petersen@oracle.com \ --cc=Sathya.Prakash@broadcom.com \ --cc=chaitra.basappa@broadcom.com \ --cc=jayant.daftardar@broadcom.com \ --cc=kashyap.desai@broadcom.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-nvme@lists.infradead.org \ --cc=linux-scsi@vger.kernel.org \ --cc=sreekanth.reddy@broadcom.com \ --cc=suganath-prabu.subramani@broadcom.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.