Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: Wgd3wbnyVO27AwQAmYOUlZr66JtXUrmiIA+gM9K3UgDRDEmeRnZqiNxZIwX1pAysXksb5t0Pml
 BwXFLGAlavSHAv3Q6EoDf6NPgwS6v3QUXfQVDW1teo9xT6fkgH5e2DI0s8mPnZTgm4lWU9ULzq
 7Uj6qf9ps3+BQGcJb5lNATTcNyoFLv3S8kk981EY2+pPPUEsG40mB+eIkitkzR+6WlrSMdOaHb
 LH928S2aEYFFCtOPms97q9CvY8H6IAuUoYm+I8tKsgBq4hOmSLxeLAe4cAY7gRHmGXlGxVhcur
 ihk=
From:   Chaitanya Kulkarni <Chaitanya.Kulkarni@wdc.com>
To:     Sagi Grimberg <sagi@grimberg.me>
CC:     Logan Gunthorpe <logang@deltatee.com>,
        Christoph Hellwig <hch@lst.de>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
        Keith Busch <kbusch@kernel.org>, Jens Axboe <axboe@fb.com>,
        Max Gurtovoy <maxg@mellanox.com>,
        Stephen Bates <sbates@raithlin.com>
Subject: Re: [PATCH v15 7/9] nvmet-passthru: Add passthru code to process
 commands
Thread-Topic: [PATCH v15 7/9] nvmet-passthru: Add passthru code to process
 commands
Thread-Index: AQHWW7Bs3rS14btVx0e0NQ0AiEjaXQ==
Date:   Mon, 20 Jul 2020 21:58:29 +0000
Message-ID: <BYAPR04MB4965E4374C4A99F326507A88867B0@BYAPR04MB4965.namprd04.prod.outlook.com>
References: <20200716203319.16022-1-logang@deltatee.com>
 <20200716203319.16022-8-logang@deltatee.com> <20200720141606.GF4627@lst.de>
 <e939dd43-9e7f-8ef0-162b-2a27f53e6e1a@grimberg.me>
 <5cc390cf-9b0b-b48b-7447-37934be51ee0@deltatee.com>
Accept-Language: en-US
Content-Language: en-US
wdcipoutbound: EOP-TRUE
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 1fc5a610-276b-433f-2423-08d82cf809a5
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2020 21:58:29.6315
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b61c8803-16f3-4c35-9b17-6f65f441df86
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: PBs5w+BJi8Sa/h/AECz5ctPtjhuJW9ZWMGV3qZRFoj1XexiaIcIm/s73BokpgQkSauSZI8L/mkSPl6lD4KYGBhye1OUFWlXeFuRDnAGXZwE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR04MB3861
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 7/20/20 14:41, Logan Gunthorpe wrote:=0A=
>> That is a neat idea! should be easy to do (and we can then lose the host=
=0A=
>> xarray stuff). I don't mind having it on a later patch, but it should be=
=0A=
>> easy enough to do even before...=0A=
>>=0A=
> I sort of follow this. I can try to work something up but it will=0A=
> probably take me a few iterations to get it to where you want it. So,=0A=
> roughly, we'd create a passthrough_q in core with the controller's IO=0A=
> tagset and then cleanup the fabrics hosts to use that instead of each=0A=
> independently creating their connect_q?=0A=
> =0A=
> Though, I don't understand how this relates to the host xarray stuff=0A=
> that Sagi mentioned...=0A=
=0A=
I didn't understand it either how having a passthru q can get rid of the=0A=
struct nvme_ns search when nsid is embedded in the nvme_cmd in=0A=
the I/O path ?=0A=
=0A=
Sagi can you please explain ?=0A=