please drop the nvme code from net-next
Shai Malin
smalin at marvell.com
Tue Jun 8 08:57:09 PDT 2021
On Tue, Jun 8, 2021 at 4:38 PM Christoph Hellwig <hch at lst.de> 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@marvell.com/
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.
More information about the Linux-nvme
mailing list