From: Frank Yang <frank.yangjie@gmail.com>
To: "Michael R. Hines" <mrhines@linux.vnet.ibm.com>
Cc: Isaku Yamahata <yamahata@private.email.ne.jp>,
yamahata@valinux.co.jp, Michael R Hines <mrhines@us.ibm.com>,
qemu-devel@nongnu.org, qemu-stable@nongnu.org
Subject: Re: [Qemu-devel] [Qemu-stable][PATCH] rdma: fix multiple VMs parallel migration
Date: Wed, 04 Sep 2013 11:23:36 +0800 [thread overview]
Message-ID: <5226A7B8.6060204@gmail.com> (raw)
In-Reply-To: <5225EEA2.4060908@linux.vnet.ibm.com>
On 2013-9-3 22:13, Michael R. Hines wrote:
>
> No top-posting, please.
>
> On 09/03/2013 12:20 AM, Frank Yang wrote:
>> Yes, it depends on low-level implementation. During my earlier test,
>> using one CQ to send and receive may cause packet loss with heavy load:
>> the destination thinks it send READY message successfully but the source
>> still waits for it. This situation always happens when the destination polls
>> receive CQE first.
>>
>> So I think using only one CQ may cause packet conflict or something like that,
>> and it should be the driver bug. However, using two CQs fix the problem.
>>
>>
>
> This doesn't seem like a very clear answer ..... are you sure its packet loss?
>
> The queue pairs are supposed to be reliable - I've never experienced a situation
> where packets were simply "dropped" for no reason without breaking the
> connection and putting the QP into an error state.
>
> - Michael
>
The fact is
1. The destination polls sending of READY message successfully. Either READY
message is sent successfully indeed and the source does not receive it, or the
destination dose not send READY message out at all.
2. I've tried to send READY message again by adding some codes during the migration.
Source can receive the READY message successfully. So the connection is not
broken and the QP works fine.
The packet loss what I'm talking about does not only refer to the loss during the
transmission. The message may also not be sent out successfully actually. ibv_poll_cq()
returns with no error, but the source dosen't receive message. For qemu, the message
it sent is lost.
next prev parent reply other threads:[~2013-09-04 3:25 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-30 12:39 [Qemu-devel] [Qemu-stable][PATCH] rdma: fix multiple VMs parallel migration Frank Yang
2013-09-02 12:46 ` Isaku Yamahata
2013-09-03 4:20 ` Frank Yang
2013-09-03 5:38 ` Lei Li
2013-09-04 3:59 ` Frank Yang
2013-09-03 14:13 ` Michael R. Hines
2013-09-04 3:23 ` Frank Yang [this message]
2013-09-03 5:03 ` Lei Li
2013-09-04 2:42 ` Frank Yang
2013-09-04 8:10 ` Frank Yang
2013-09-24 17:59 ` [Qemu-devel] [Qemu-stable] [PATCH] " Michael R. Hines
2013-10-10 13:38 ` Frank Yang
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=5226A7B8.6060204@gmail.com \
--to=frank.yangjie@gmail.com \
--cc=mrhines@linux.vnet.ibm.com \
--cc=mrhines@us.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-stable@nongnu.org \
--cc=yamahata@private.email.ne.jp \
--cc=yamahata@valinux.co.jp \
/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;
as well as URLs for NNTP newsgroup(s).