From: Christoph Hellwig <hch@lst.de>
To: Sagi Grimberg <sagi@grimberg.me>
Cc: Christoph Hellwig <hch@infradead.org>,
Keith Busch <keith.busch@intel.com>,
linux-block@vger.kernel.org, Christoph Hellwig <hch@lst.de>,
linux-nvme@lists.infradead.org
Subject: Re: Centralize nvme controller reset, delete and fabrics periodic reconnects
Date: Wed, 16 Aug 2017 11:35:59 +0200 [thread overview]
Message-ID: <20170816093559.GA24709@lst.de> (raw)
In-Reply-To: <964d191e-0fe4-e440-71e6-0fd186d4f52b@grimberg.me>
On Wed, Aug 16, 2017 at 12:33:47PM +0300, Sagi Grimberg wrote:
>>> This set applies on nvme-4.14 plus 4.13 recent fixes.
>>
>> I can't get this applied at all.
>
> That's probably because this is on top of the rdma affinity
> patches which are already in Doug's tree...
>
>> A pointer to a git repo would
>> always be nice for patchsets as large as this one, especially if
>> the base is a bit murky..
>
> 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.
If it's in a branch of its own we could pull it in through and
send that bit through both trees.
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:35:59 +0200 [thread overview]
Message-ID: <20170816093559.GA24709@lst.de> (raw)
In-Reply-To: <964d191e-0fe4-e440-71e6-0fd186d4f52b@grimberg.me>
On Wed, Aug 16, 2017@12:33:47PM +0300, Sagi Grimberg wrote:
>>> This set applies on nvme-4.14 plus 4.13 recent fixes.
>>
>> I can't get this applied at all.
>
> That's probably because this is on top of the rdma affinity
> patches which are already in Doug's tree...
>
>> A pointer to a git repo would
>> always be nice for patchsets as large as this one, especially if
>> the base is a bit murky..
>
> 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.
If it's in a branch of its own we could pull it in through and
send that bit through both trees.
next prev parent reply other threads:[~2017-08-16 9:36 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 [this message]
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
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=20170816093559.GA24709@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.