linux-kernel - RE: please drop the nvme code from net-next

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <SJ0PR18MB38822C7D07B54625B26C39A6CC379@SJ0PR18MB3882.namprd18.prod.outlook.com>
Date:   Tue, 8 Jun 2021 15:56:45 +0000
From:   Shai Malin <smalin@...vell.com>
To:     Christoph Hellwig <hch@....de>,
        Geert Uytterhoeven <geert@...ux-m68k.org>
CC:     "David S . Miller" <davem@...emloft.net>,
        Keith Busch <kbusch@...nel.org>, Jens Axboe <axboe@...com>,
        Sagi Grimberg <sagi@...mberg.me>,
        Omkar Kulkarni <okulkarni@...vell.com>,
        Hannes Reinecke <hare@...e.de>,
        Dean Balandin <dbalandin@...vell.com>,
        Himanshu Madhani <himanshu.madhani@...cle.com>,
        Petr Mladek <pmladek@...e.com>,
        "linux-nvme@...ts.infradead.org" <linux-nvme@...ts.infradead.org>,
        netdev <netdev@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: RE: please drop the nvme code from net-next


On Tue, Jun 8, 2021 at 4:38 PM Christoph Hellwig <hch@....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.