All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shai Malin <smalin@marvell.com>
To: Christoph Hellwig <hch@lst.de>,
	Geert Uytterhoeven <geert@linux-m68k.org>
Cc: "David S . Miller" <davem@davemloft.net>,
	Keith Busch <kbusch@kernel.org>, Jens Axboe <axboe@fb.com>,
	Sagi Grimberg <sagi@grimberg.me>,
	Omkar Kulkarni <okulkarni@marvell.com>,
	Hannes Reinecke <hare@suse.de>,
	Dean Balandin <dbalandin@marvell.com>,
	Himanshu Madhani <himanshu.madhani@oracle.com>,
	Petr Mladek <pmladek@suse.com>,
	"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
	netdev <netdev@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: RE: please drop the nvme code from net-next
Date: Tue, 8 Jun 2021 15:56:45 +0000	[thread overview]
Message-ID: <SJ0PR18MB38822C7D07B54625B26C39A6CC379@SJ0PR18MB3882.namprd18.prod.outlook.com> (raw)


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

WARNING: multiple messages have this Message-ID (diff)
From: Shai Malin <smalin@marvell.com>
To: Christoph Hellwig <hch@lst.de>,
	Geert Uytterhoeven <geert@linux-m68k.org>
Cc: "David S . Miller" <davem@davemloft.net>,
	Keith Busch <kbusch@kernel.org>,  Jens Axboe <axboe@fb.com>,
	Sagi Grimberg <sagi@grimberg.me>,
	Omkar Kulkarni <okulkarni@marvell.com>,
	Hannes Reinecke <hare@suse.de>,
	Dean Balandin <dbalandin@marvell.com>,
	Himanshu Madhani <himanshu.madhani@oracle.com>,
	Petr Mladek <pmladek@suse.com>,
	"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
	netdev <netdev@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: RE: please drop the nvme code from net-next
Date: Tue, 8 Jun 2021 15:56:45 +0000	[thread overview]
Message-ID: <SJ0PR18MB38822C7D07B54625B26C39A6CC379@SJ0PR18MB3882.namprd18.prod.outlook.com> (raw)


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

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

             reply	other threads:[~2021-06-08 15:57 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-08 15:56 Shai Malin [this message]
2021-06-08 15:56 ` please drop the nvme code from net-next Shai Malin
  -- strict thread matches above, loose matches on Subject: below --
2021-06-08 19:51 Shai Malin
2021-06-08 19:51 ` Shai Malin
2021-06-09 12:13 ` Shai Malin
2021-06-09 12:13   ` Shai Malin
2021-06-08 10:56 [PATCH] nvme: NVME_TCP_OFFLOAD should not default to m Geert Uytterhoeven
2021-06-08 12:19 ` Christoph Hellwig
2021-06-08 13:37   ` Geert Uytterhoeven
2021-06-08 13:43     ` please drop the nvme code from net-next Christoph Hellwig
2021-06-08 13:43       ` Christoph Hellwig
2021-06-08 19:08       ` David Miller
2021-06-08 19:08         ` David Miller
2021-06-08 19:40         ` Keith Busch
2021-06-08 19:40           ` Keith Busch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=SJ0PR18MB38822C7D07B54625B26C39A6CC379@SJ0PR18MB3882.namprd18.prod.outlook.com \
    --to=smalin@marvell.com \
    --cc=axboe@fb.com \
    --cc=davem@davemloft.net \
    --cc=dbalandin@marvell.com \
    --cc=geert@linux-m68k.org \
    --cc=hare@suse.de \
    --cc=hch@lst.de \
    --cc=himanshu.madhani@oracle.com \
    --cc=kbusch@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=netdev@vger.kernel.org \
    --cc=okulkarni@marvell.com \
    --cc=pmladek@suse.com \
    --cc=sagi@grimberg.me \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.