All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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: link
Be 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.