[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BYAPR04MB4965E4374C4A99F326507A88867B0@BYAPR04MB4965.namprd04.prod.outlook.com>
Date: Mon, 20 Jul 2020 21:58:29 +0000
From: Chaitanya Kulkarni <Chaitanya.Kulkarni@....com>
To: Sagi Grimberg <sagi@...mberg.me>
CC: Logan Gunthorpe <logang@...tatee.com>,
Christoph Hellwig <hch@....de>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-nvme@...ts.infradead.org" <linux-nvme@...ts.infradead.org>,
Keith Busch <kbusch@...nel.org>, Jens Axboe <axboe@...com>,
Max Gurtovoy <maxg@...lanox.com>,
Stephen Bates <sbates@...thlin.com>
Subject: Re: [PATCH v15 7/9] nvmet-passthru: Add passthru code to process
commands
On 7/20/20 14:41, Logan Gunthorpe wrote:
>> That is a neat idea! should be easy to do (and we can then lose the host
>> xarray stuff). I don't mind having it on a later patch, but it should be
>> easy enough to do even before...
>>
> I sort of follow this. I can try to work something up but it will
> probably take me a few iterations to get it to where you want it. So,
> roughly, we'd create a passthrough_q in core with the controller's IO
> tagset and then cleanup the fabrics hosts to use that instead of each
> independently creating their connect_q?
>
> Though, I don't understand how this relates to the host xarray stuff
> that Sagi mentioned...
I didn't understand it either how having a passthru q can get rid of the
struct nvme_ns search when nsid is embedded in the nvme_cmd in
the I/O path ?
Sagi can you please explain ?
Powered by blists - more mailing lists