RE: please drop the nvme code from net-next

[Shai Malin]

On Tue, Jun 8, 2021 at 4:38 PM Christoph Hellwig <hch@xxxxxx> wrote:
> Hi Dave,
> 
> please drop the nvme-offload code from net-next.  Code for drivers/nvme/
> needs ACKs from us nvme maintainers and for something this significant
> also needs to go through the NVMe tree.  And this code is not ready yet.

Hi all,

Sorry for any confusion we may have caused. Our plan was for the qed series 
to be considered for net-next, and for the nvme-tcp-offload series to be 
considered for nvme mailing list.
We attempted to communicate this in the cover letter and the addresses 
in to: vs. those in cc:, but perhaps this was not clear enough.

The plan was detailed in the cover latter under the "upstream plan" section 
https://lore.kernel.org/netdev/20210531225222.16992-1-smalin@xxxxxxxxxxx/
The series is structured in a modular way so that part 1 (nvme-tcp-offload) 
and part 2 (qed) are independent and part 3 (qedn) depends on both parts 1+2.

We have sent the first 2 parts which are independent:

- QED NVMeTCP Offload - https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=eda1bc65b0dc1b03006e427430ba23746ec44714
  This part includes the qed infrastructure which was discussed over the RFC.
  Our intent for this part was for it to be accepted to net-next, which it was.
  Dave, from our perspective this piece can stay in net-next.

- NVMeTCP Offload ULP - https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=5ff5622ea1f16d535f1be4e478e712ef48fe183b
  This is the nvme-tcp-offload ULP which we intended the NVMe tree,
  and it shouldn't be merged to net-next.
  Dave, please revert this from net-next until nvme maintainers are completely 
  satisfied with it.

Christoph, we would be more than happy to incorporate any feedback you may 
provide for any part of the series.