Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <dca2b65a-2b76-50ed-7c58-e304efe1021c@grimberg.me>
Date:   Thu, 4 May 2023 13:25:27 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.10.0
Subject: Re: [RFC v3 0/9] Unifying fabrics drivers
Content-Language: en-US
To:     Daniel Wagner <dwagner@suse.de>, linux-nvme@lists.infradead.org
Cc:     linux-kernel@vger.kernel.org, Chaitanya Kulkarni <kch@nvidia.com>,
        Hannes Reinecke <hare@suse.de>,
        James Smart <jsmart2021@gmail.com>
References: <20230504091259.29100-1-dwagner@suse.de>
From:   Sagi Grimberg <sagi@grimberg.me>
In-Reply-To: <20230504091259.29100-1-dwagner@suse.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

> I've rebased on nvme-6.4 and gave it a bit of testing. Up to the last patch it seems to
> work fine, at least blktests doesn't trigger any errors.
> 
> I've tried to split the pure moving code around part from the part where we need
> to change some code. That means the last two patches highlight the problems I
> run into with this attempt to implement the setup_transport() callback

This should be perfectly fine covering loop as well. I think that
eventually it can cover pci as well, but we can promote it there in
time perhaps.