Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752145AbdHHHDn (ORCPT ); Tue, 8 Aug 2017 03:03:43 -0400 Received: from mail-pg0-f52.google.com ([74.125.83.52]:33105 "EHLO mail-pg0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751880AbdHHHDl (ORCPT ); Tue, 8 Aug 2017 03:03:41 -0400 MIME-Version: 1.0 In-Reply-To: <20170808040449.GE842@localhost.localdomain> References: <1500038560-11231-1-git-send-email-suganath-prabu.subramani@broadcom.com> <20170805135353.GA7526@infradead.org> <1501944129.3649.9.camel@HansenPartnership.com> <0ada8680ebfeb026662d858ec2b38ef4@mail.gmail.com> <1502115492.2841.20.camel@HansenPartnership.com> <1502120725.2841.28.camel@HansenPartnership.com> <20170808040449.GE842@localhost.localdomain> From: Sreekanth Reddy Date: Tue, 8 Aug 2017 12:33:40 +0530 Message-ID: Subject: Re: [PATCH v2 00/13] mpt3sas driver NVMe support: To: Keith Busch Cc: James Bottomley , Kashyap Desai , Christoph Hellwig , Hannes Reinecke , "linux-scsi@vger.kernel.org" , Chaitra Basappa , Suganath Prabu Subramani , Sathya Prakash Veerichetty , "linux-kernel@vger.kernel.org" , linux-nvme@lists.infradead.org, "Martin K. Petersen" 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: 2060 Lines: 47 On Tue, Aug 8, 2017 at 9:34 AM, Keith Busch wrote: > On Mon, Aug 07, 2017 at 08:45:25AM -0700, James Bottomley wrote: >> On Mon, 2017-08-07 at 20:01 +0530, Kashyap Desai wrote: >> > >> > We have to attempt this use case and see how it behaves. I have not >> > tried this, so not sure if things are really bad or just some tuning >> > may be helpful. I will revert back to you on this. >> > >> > I understood request as - We need some udev rules to be working well >> > for *same* NVME drives if it is behind or native . >> > Example - If user has OS installed on NVME drive which is behind >> > driver as SCSI disk should be able to boot if he/she hooked >> > same NVME drive which is detected by native driver (and vice >> > versa.) >> >> It's not just the udev rules, it's the tools as well; possibly things >> like that nvme-cli toolkit Intel is doing. > > It looks like they can make existing nvme tooling work with little > effort if they have the driver implement NVME_IOCTL_ADMIN_COMMAND, and Precisely, I was thinking on the same line and you clarified. I will spend sometime on this and get back to you. > then have their driver build the MPI NVMe Encapsulated Request from that. Hi Everyone, Thanks for the discussion and feedback. We have noted this (i.e. will Encapsulate NVME_IOCTL_ADMIN_CMD received from nvme cli in to MPI NVMe Encapsulated Request message and will issue this request to firmware) as our next to-do item and I will post possible options (this may need some discussion with our FW group, so need time to get back with all the details). We will be posting next version of patch set i.e. v3, which will a accommodate below changes suggested by Hannes and Martin over v2 patch set. 1. In the MPI header files, we have reformatted headers to have type and variable on one line as suggested by Hannes, 2. As suggested by Martin, started using blk_queue_virt_boundary() API for NVMe drives and simplified the PRP formation. 3. Removed 'TODO' comments Thanks, Sreekanth