From: Christoph Hellwig <hch@lst.de>
To: Sagi Grimberg <sagi@grimberg.me>
Cc: Christoph Hellwig <hch@lst.de>,
Christoph Hellwig <hch@infradead.org>,
Keith Busch <keith.busch@intel.com>,
linux-block@vger.kernel.org, linux-nvme@lists.infradead.org
Subject: Re: Centralize nvme controller reset, delete and fabrics periodic reconnects
Date: Wed, 16 Aug 2017 11:57:07 +0200 [thread overview]
Message-ID: <20170816095707.GA26561@lst.de> (raw)
In-Reply-To: <ca050b6b-6694-834c-51ab-856b516bd6ad@grimberg.me>
On Wed, Aug 16, 2017 at 12:46:25PM +0300, Sagi Grimberg wrote:
>>> Sure, should I have it on top of the affinity patches or not?
>>
>> For now get any tree you have out to take a look. In the longer
>> run we'll need to decide how we want to deal with the merge
>> of the two trees. In general having to depend on the RDMA
>> tree is a major risk because it's maintainance is so unreliable.
>
> Its really a small conflict, easy enough to get it without. The problem
> that no matter what I do, one tree would conflict...
Let's keep the refactoring self contained in nvme now and sort out
the small conflict when the rdma tree is merge (which is alsmost
certainly going to be after the block tree)
WARNING: multiple messages have this Message-ID (diff)
From: hch@lst.de (Christoph Hellwig)
Subject: Centralize nvme controller reset, delete and fabrics periodic reconnects
Date: Wed, 16 Aug 2017 11:57:07 +0200 [thread overview]
Message-ID: <20170816095707.GA26561@lst.de> (raw)
In-Reply-To: <ca050b6b-6694-834c-51ab-856b516bd6ad@grimberg.me>
On Wed, Aug 16, 2017@12:46:25PM +0300, Sagi Grimberg wrote:
>>> Sure, should I have it on top of the affinity patches or not?
>>
>> For now get any tree you have out to take a look. In the longer
>> run we'll need to decide how we want to deal with the merge
>> of the two trees. In general having to depend on the RDMA
>> tree is a major risk because it's maintainance is so unreliable.
>
> Its really a small conflict, easy enough to get it without. The problem
> that no matter what I do, one tree would conflict...
Let's keep the refactoring self contained in nvme now and sort out
the small conflict when the rdma tree is merge (which is alsmost
certainly going to be after the block tree)
next prev parent reply other threads:[~2017-08-16 9:57 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-15 9:52 Centralize nvme controller reset, delete and fabrics periodic reconnects Sagi Grimberg
2017-08-15 9:52 ` Sagi Grimberg
2017-08-15 9:52 ` [PATCH 01/12] nvme: move err and reconnect work to nvme ctrl Sagi Grimberg
2017-08-15 9:52 ` Sagi Grimberg
2017-08-15 9:52 ` [PATCH 02/12] nvme-rdma: move admin specific resources to alloc_queue Sagi Grimberg
2017-08-15 9:52 ` Sagi Grimberg
2017-08-15 9:52 ` [PATCH 03/12] nvme-rdma: split nvme_rdma_alloc_io_queues Sagi Grimberg
2017-08-15 9:52 ` Sagi Grimberg
2017-08-15 9:52 ` [PATCH 04/12] nvme-rdma: restructure create_ctrl a bit Sagi Grimberg
2017-08-15 9:52 ` Sagi Grimberg
2017-08-15 9:52 ` [PATCH 05/12] nvme-rdma: introduce nvme_rdma_alloc/stop/free_admin_queue Sagi Grimberg
2017-08-15 9:52 ` Sagi Grimberg
2017-08-15 9:52 ` [PATCH 06/12] nvme-rdma: plumb nvme ctrl to various routines Sagi Grimberg
2017-08-15 9:52 ` Sagi Grimberg
2017-08-15 9:52 ` [PATCH 07/12] nvme-rdma: split generic probe out of create_ctrl Sagi Grimberg
2017-08-15 9:52 ` Sagi Grimberg
2017-08-15 9:52 ` [PATCH 08/12] nvme: add some ctrl ops for centralizing control plane logic Sagi Grimberg
2017-08-15 9:52 ` Sagi Grimberg
2017-08-15 9:52 ` [PATCH 09/12] nvme: move control plane handling to nvme core Sagi Grimberg
2017-08-15 9:52 ` Sagi Grimberg
2017-08-15 9:52 ` [PATCH 10/12] nvme-fabrics: handle reconnects in fabrics library Sagi Grimberg
2017-08-15 9:52 ` Sagi Grimberg
2017-08-15 9:52 ` [PATCH 11/12] nvme: add sed-opal ctrl manipulation in admin configuration Sagi Grimberg
2017-08-15 9:52 ` Sagi Grimberg
2017-08-15 9:52 ` [PATCH 12/12] nvme-loop: convert to nvme-core control plane management Sagi Grimberg
2017-08-15 9:52 ` Sagi Grimberg
2017-08-16 8:16 ` Centralize nvme controller reset, delete and fabrics periodic reconnects Christoph Hellwig
2017-08-16 8:16 ` Christoph Hellwig
2017-08-16 9:33 ` Sagi Grimberg
2017-08-16 9:33 ` Sagi Grimberg
2017-08-16 9:35 ` Christoph Hellwig
2017-08-16 9:35 ` Christoph Hellwig
2017-08-16 9:46 ` Sagi Grimberg
2017-08-16 9:46 ` Sagi Grimberg
2017-08-16 9:57 ` Christoph Hellwig [this message]
2017-08-16 9:57 ` Christoph Hellwig
2017-08-16 10:09 ` Sagi Grimberg
2017-08-16 10:09 ` Sagi Grimberg
2017-08-16 10:49 ` Christoph Hellwig
2017-08-16 10:49 ` Christoph Hellwig
2017-08-16 13:51 ` Sagi Grimberg
2017-08-16 13:51 ` Sagi Grimberg
2017-08-16 15:17 ` Christoph Hellwig
2017-08-16 15:17 ` Christoph Hellwig
2017-08-17 7:21 ` Sagi Grimberg
2017-08-17 7:21 ` Sagi Grimberg
2017-08-17 7:36 ` Christoph Hellwig
2017-08-17 7:36 ` Christoph Hellwig
2017-08-20 6:37 ` Sagi Grimberg
2017-08-20 6:37 ` Sagi Grimberg
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=20170816095707.GA26561@lst.de \
--to=hch@lst.de \
--cc=hch@infradead.org \
--cc=keith.busch@intel.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--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.