From: Suganath Prabu Subramani <suganath-prabu.subramani@broadcom.com> To: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: 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 Subject: Re: [PATCH v4 00/14] mpt3sas driver NVMe support: Date: Mon, 18 Sep 2017 16:09:09 +0530 [thread overview] Message-ID: <CA+RiK65GPnfqpQAuUWEs_NdW9crumkGparCqynN_dBti8BPXqQ@mail.gmail.com> (raw) In-Reply-To: <yq1wp50rcqw.fsf@oracle.com> Hi Martin, On Fri, Sep 15, 2017 at 6:37 AM, Martin K. Petersen <martin.petersen@oracle.com> wrote: > > Suganath, > >> Is there any update on the submitted mpt3sas patches. > > We are waiting for you to report back your findings on PRP vs. SGL. We are working on this, since there is h/w dependent, we are in discussion with H/W & F/W team and doing experiments. If there is no impact, and if SGL translation has to be removed, this change has to go through some phase of testing, before we post it to upstream, since that is not inline with H/W requirement. The hardware translation of IEEE SGL to NVMe PRPs has limitation. We have added the below comment in patch 3 as well: if a command cannot be translated by hardware then it will go to firmware and the firmware needs to translate it. And this will have a performance reduction. To avoid that driver proactively checks whether the translation will be done in hardware or not, if not then driver try to translate inside the driver Current code posted to upstream is inline with hardware requirements and well tested internally. SGL vs NVMe PRP building in driver is small sanity check for decision making and it is not going to change in long run. 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. 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). Hope this clarifies. > > -- > Martin K. Petersen Oracle Linux Engineering Thanks, Suganath Prabu S
WARNING: multiple messages have this Message-ID (diff)
From: suganath-prabu.subramani@broadcom.com (Suganath Prabu Subramani) Subject: [PATCH v4 00/14] mpt3sas driver NVMe support: Date: Mon, 18 Sep 2017 16:09:09 +0530 [thread overview] Message-ID: <CA+RiK65GPnfqpQAuUWEs_NdW9crumkGparCqynN_dBti8BPXqQ@mail.gmail.com> (raw) In-Reply-To: <yq1wp50rcqw.fsf@oracle.com> Hi Martin, On Fri, Sep 15, 2017 at 6:37 AM, Martin K. Petersen <martin.petersen@oracle.com> wrote: > > Suganath, > >> Is there any update on the submitted mpt3sas patches. > > We are waiting for you to report back your findings on PRP vs. SGL. We are working on this, since there is h/w dependent, we are in discussion with H/W & F/W team and doing experiments. If there is no impact, and if SGL translation has to be removed, this change has to go through some phase of testing, before we post it to upstream, since that is not inline with H/W requirement. The hardware translation of IEEE SGL to NVMe PRPs has limitation. We have added the below comment in patch 3 as well: if a command cannot be translated by hardware then it will go to firmware and the firmware needs to translate it. And this will have a performance reduction. To avoid that driver proactively checks whether the translation will be done in hardware or not, if not then driver try to translate inside the driver Current code posted to upstream is inline with hardware requirements and well tested internally. SGL vs NVMe PRP building in driver is small sanity check for decision making and it is not going to change in long run. 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. 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). Hope this clarifies. > > -- > Martin K. Petersen Oracle Linux Engineering Thanks, Suganath Prabu S
next prev parent reply other threads:[~2017-09-18 10:39 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 [this message] 2017-09-18 10:39 ` Suganath Prabu Subramani 2017-09-25 20:22 ` Martin K. Petersen 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=CA+RiK65GPnfqpQAuUWEs_NdW9crumkGparCqynN_dBti8BPXqQ@mail.gmail.com \ --to=suganath-prabu.subramani@broadcom.com \ --cc=Sathya.Prakash@broadcom.com \ --cc=chaitra.basappa@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=martin.petersen@oracle.com \ --cc=sreekanth.reddy@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.