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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox