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

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