From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751648AbdIMHPL (ORCPT ); Wed, 13 Sep 2017 03:15:11 -0400 Received: from mail-it0-f41.google.com ([209.85.214.41]:38854 "EHLO mail-it0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751393AbdIMHPI (ORCPT ); Wed, 13 Sep 2017 03:15:08 -0400 X-Google-Smtp-Source: AOwi7QDCU/OwmtXwx24NV+96s9u1w4awDLviUFF4hi6JQtXIob87l5PdSy0i02ZVbeFfW3AUBK6OPk/ueZ2RA2iTFTw= MIME-Version: 1.0 In-Reply-To: References: <1503322344-5900-1-git-send-email-suganath-prabu.subramani@broadcom.com> From: Suganath Prabu Subramani Date: Wed, 13 Sep 2017 12:45:06 +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 Hi Martin, Is there any update on the submitted mpt3sas patches. Thanks, Suganath Prabu S On Fri, Sep 1, 2017 at 2:09 PM, Suganath Prabu Subramani wrote: > Hi Martin, > > On Fri, Sep 1, 2017 at 8:52 AM, Martin K. Petersen > wrote: >> >> Hi Suganath, >> >>> Let me explain - NVME device fast path is possible in two ways. IEEE >>> SGL and PRP SGL. Due to h/w constraint we choose IEEE SGL only for >>> smaller IO size. Both above is true h/w Fast Path and no firmware >>> involvement. >> >>> Agree with you. We are planning to see if we can keep only simple Fast >>> Path using only PRP. >> >> That would be great, thank you! >> >>> Currently there is no performance issue for UNMAP translation in FW. >> >> Good! >> >>>> And yet patch 4 circumvents that statement by adding support for >>>> encapsulated commands to bypass the FW translation... >>> >>> This path is not due to performance reason. User wants to interact >>> with NVME drive in native NVME command for management. >> >> Patch 4 states: >> >> "This encapsulated NVMe command is used by applications to send direct >> NVMe commands to NVMe drives or for handling unmap where the translation >> at controller/firmware level is having performance issues." >> >> -- > > The statement in description of patch 4 is added by mistake, We ll > correct the description and re sending that. > >> Martin K. Petersen Oracle Linux Engineering > > Thanks, > Suganath Prabu S From mboxrd@z Thu Jan 1 00:00:00 1970 From: suganath-prabu.subramani@broadcom.com (Suganath Prabu Subramani) Date: Wed, 13 Sep 2017 12:45:06 +0530 Subject: [PATCH v4 00/14] mpt3sas driver NVMe support: In-Reply-To: References: <1503322344-5900-1-git-send-email-suganath-prabu.subramani@broadcom.com> Message-ID: Hi Martin, Is there any update on the submitted mpt3sas patches. Thanks, Suganath Prabu S On Fri, Sep 1, 2017 at 2:09 PM, Suganath Prabu Subramani wrote: > Hi Martin, > > On Fri, Sep 1, 2017 at 8:52 AM, Martin K. Petersen > wrote: >> >> Hi Suganath, >> >>> Let me explain - NVME device fast path is possible in two ways. IEEE >>> SGL and PRP SGL. Due to h/w constraint we choose IEEE SGL only for >>> smaller IO size. Both above is true h/w Fast Path and no firmware >>> involvement. >> >>> Agree with you. We are planning to see if we can keep only simple Fast >>> Path using only PRP. >> >> That would be great, thank you! >> >>> Currently there is no performance issue for UNMAP translation in FW. >> >> Good! >> >>>> And yet patch 4 circumvents that statement by adding support for >>>> encapsulated commands to bypass the FW translation... >>> >>> This path is not due to performance reason. User wants to interact >>> with NVME drive in native NVME command for management. >> >> Patch 4 states: >> >> "This encapsulated NVMe command is used by applications to send direct >> NVMe commands to NVMe drives or for handling unmap where the translation >> at controller/firmware level is having performance issues." >> >> -- > > The statement in description of patch 4 is added by mistake, We ll > correct the description and re sending that. > >> Martin K. Petersen Oracle Linux Engineering > > Thanks, > Suganath Prabu S