From: dingxiang@huawei.com (dingxiang)
Subject: Question about NVMe share I/O
Date: Thu, 2 Jul 2015 15:11:49 +0800 [thread overview]
Message-ID: <5594E435.8060306@huawei.com> (raw)
In-Reply-To: <alpine.LNX.2.00.1507011612070.15930@localhost.lm.intel.com>
? 2015/7/2 0:17, Keith Busch wrote:
> On Tue, 30 Jun 2015, dingxiang wrote:
>> Hi,All
>> We are now using NVMe to develop a share I/O model,the topology is
>>
>> |------| |------|
>> |Host A| |Host B|
>> |______| |______|
>> \ /
>> \ /
>> \ |------| /
>> \| nvme |/
>> |______|
>
>
> I think I'm missing part of the picture here. Could you explain how
> you managed to get two hosts to talk to a single nvme controller. More
> specifically, how are they able to safely share the admin queue and the
> pci-e function's nvme registers?
>
>
We create admin queue and an I/O queue(QID:1) in nvme server before Host A&B start,
host A&B send amdin commands to nvme controller through a PLX chip,then nvme controller
can handle admin commands that from host A&B,and there is no error in admin commands pci-e
messages, host A&B can create I/O queue and perform other amdin commands normally .
So Host A&B can share the admin queue and the pci-e function's nvme registers safely.
>> We assign one queue for every host,
>> here are the details of host A and B:
>>
>> Host A:
>> QID :2
>> MSIX irq:117
>> cq prp1 :0x31253530000
>> sq prp1 :0x3124af30000
>>
>> Host B:
>> QID :3
>> MSIX irq:118
>> cq prp1 :0x35252470000
>> sq prp1 :0x3524d820000
>>
>> Then we run test script in both hosts,the script is :
>> insmod nvme.ko
>> sleep 2
>> rmmod nvme
>> sleep 2
>>
>> When the script runs after a period of time,Host B will crash in function "nvme_process_cq",
>> and Host A will print "I/O Buffer error" messages.
>> We found when host B crash,the QID Host B processed is QID 2,and the command_id
>> in struct "nvme_completion" is not the value allocate in Host B, but same as Host A ,
>> the MSIX and prp value of host B are not change.
>> My doubt is why Host B can receive Host A's nvmeq info? In my opinion,the queues of Host A and B
>> are independent, should not interfere with each other.
>> Thanks!
>
> .
>
next prev parent reply other threads:[~2015-07-02 7:11 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-08 16:08 [PATCH 0/3] NVMe: Initialization error handling fixups Keith Busch
2015-06-08 16:08 ` [PATCH 1/3] NVMe: Fix device cleanup on initialization failure Keith Busch
2015-06-08 16:08 ` [PATCH 2/3] NVMe: Don't use fake status on cancelled command Keith Busch
2015-06-11 10:40 ` Christoph Hellwig
2015-06-11 14:15 ` Keith Busch
2015-06-11 15:23 ` Christoph Hellwig
[not found] ` <55935989.70809@huawei.com>
2015-07-01 16:17 ` Question about NVMe share I/O Keith Busch
2015-07-01 16:45 ` James R. Bergsten
2015-07-02 7:11 ` dingxiang [this message]
2015-07-02 12:42 ` Yijing Wang
2015-07-02 14:42 ` Keith Busch
2015-07-03 1:24 ` Yijing Wang
2015-07-08 8:49 ` dingxiang
2015-06-08 16:08 ` [PATCH 3/3] NVMe: Unify controller probe and resume 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=5594E435.8060306@huawei.com \
--to=dingxiang@huawei.com \
/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.