Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752693AbdIRKjM (ORCPT ); Mon, 18 Sep 2017 06:39:12 -0400 Received: from mail-it0-f47.google.com ([209.85.214.47]:45534 "EHLO mail-it0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751365AbdIRKjK (ORCPT ); Mon, 18 Sep 2017 06:39:10 -0400 X-Google-Smtp-Source: AOwi7QCATaD4aackayaCEgyexiy4GqfDV+l0jOdrViRpOHkyXLCg7UGsS6uiqSQnh+d5pyWQPI+JpNabPKyuS+3Ho7s= MIME-Version: 1.0 In-Reply-To: References: <1503322344-5900-1-git-send-email-suganath-prabu.subramani@broadcom.com> From: Suganath Prabu Subramani Date: Mon, 18 Sep 2017 16:09:09 +0530 Message-ID: Subject: Re: [PATCH v4 00/14] mpt3sas driver NVMe support: To: "Martin K. Petersen" Cc: linux-scsi@vger.kernel.org, Sathya Prakash , Kashyap Desai , linux-kernel@vger.kernel.org, Chaitra Basappa , Sreekanth Reddy , linux-nvme@lists.infradead.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1649 Lines: 48 Hi Martin, On Fri, Sep 15, 2017 at 6:37 AM, Martin K. Petersen 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