linux-kernel - Re: [PATCH v4 00/14] mpt3sas driver NVMe support:

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+RiK65GPnfqpQAuUWEs_NdW9crumkGparCqynN_dBti8BPXqQ@mail.gmail.com>
Date:   Mon, 18 Sep 2017 16:09:09 +0530
From:   Suganath Prabu Subramani <suganath-prabu.subramani@...adcom.com>
To:     "Martin K. Petersen" <martin.petersen@...cle.com>
Cc:     linux-scsi@...r.kernel.org,
        Sathya Prakash <Sathya.Prakash@...adcom.com>,
        Kashyap Desai <kashyap.desai@...adcom.com>,
        linux-kernel@...r.kernel.org,
        Chaitra Basappa <chaitra.basappa@...adcom.com>,
        Sreekanth Reddy <sreekanth.reddy@...adcom.com>,
        linux-nvme@...ts.infradead.org
Subject: Re: [PATCH v4 00/14] mpt3sas driver NVMe support:

Hi Martin,

On Fri, Sep 15, 2017 at 6:37 AM, Martin K. Petersen
<martin.petersen@...cle.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