From: Paolo Bonzini <pbonzini@redhat.com>
To: "Michael R. Hines" <mrhines@linux.vnet.ibm.com>
Cc: aliguori@us.ibm.com, mst@redhat.com, qemu-devel@nongnu.org,
owasserm@redhat.com, abali@us.ibm.com, mrhines@us.ibm.com,
gokul@us.ibm.com
Subject: Re: [Qemu-devel] [PULL 5/8] rdma: core rdma logic
Date: Wed, 17 Apr 2013 18:48:18 +0200 [thread overview]
Message-ID: <516ED252.7090609@redhat.com> (raw)
In-Reply-To: <516EC6F9.4070103@linux.vnet.ibm.com>
Il 17/04/2013 17:59, Michael R. Hines ha scritto:
>>> Failure already happens for unknown capabilities.
>> Maybe I misread the code, but all I saw is:
>>
>> + if (cap.flags & RDMA_CAPABILITY_CHUNK_REGISTER) {
>> + rdma->chunk_register_destination = true;
>> + } else if (cap.flags & RDMA_CAPABILITY_NEXT_FEATURE) {
>> + /* handle new capability */
>> + }
>>
>> and no failure. I may well be wrong of course.
>
> Sorry I miscommunicated. By "failure" I meant "disagreement".
> My design allows the two sides to "agree" with each other as I
> included in the documentation like this:
>
> 1. User sets capability on source (or not)
>
> 2. If 'true', source transmits our "intent" to activate capability to
> destination
>
> If (destination knows about the capability)
> then, enable on both sides
> else
> disable on both sides
>
> 3. If 'false', destination will never see the flag and will never know
Great. That was my understanding too.
>>>> + goto err_rdma_server_wait;
>>>> + }
>>>> +
>>>> + if (cap.version == RDMA_CONTROL_VERSION_1) {
>>>> + if (cap.flags & RDMA_CAPABILITY_CHUNK_REGISTER) {
>>>> + rdma->chunk_register_destination = true;
>>>> + } else if (cap.flags & RDMA_CAPABILITY_NEXT_FEATURE) {
>>>> + /* handle new capability */
>>>> + }
>>>> As mentioned above, please drop this "else if". But in general, this
>>>> "if" is useless. Please replace it with an
>>>>
>>>> /* We only support one version, and we rejected all
>>>> * others above.
>>>> */
>>>> assert(cap.version == RDMA_CONTROL_VERSION_CURRENT);
>>> We don't want to kill QEMU with an assertion, do we?
>>> Shouldn't we throw the error back to the user?
>> You already filtered versions < min and > current with a decent error,
>> so the only reamining version at this point is 1. You know cap.version
>> == RDMA_CONTROL_VERSION_CURRENT ("we rejected all others above").
>
> So, as I described above, when version 2 comes out, both QEMU
> instances are able to "agree" only on the minimum capabilities
> that both sides support and still allow the migration to begin.
>
> For that reason, I don't think we should be doing assert() here.
> We want this to be compatible across multiple QEMU versions.
The point of the assert is to ensure that all versions are either
handled correctly, or rejected. It's to distinguish bugs from
unsupported versions.
switch (cap.version) {
case RDMA_CONTROL_VERSION_CURRENT:
...;
break;
default:
assert(cap.version < RDMA_CONTROL_VERSION_MIN ||
cap.version > RDMA_CONTROL_VERSION_CURRENT);
/* give error */
}
Then you can simply add new cases when new versions come out.
Paolo
next prev parent reply other threads:[~2013-04-17 16:48 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-16 2:44 [Qemu-devel] [PULL 0/8] rdma: migration support mrhines
2013-04-16 2:44 ` [Qemu-devel] [PULL 1/8] rdma: introduce qemu_ram_foreach_block mrhines
2013-04-16 2:44 ` [Qemu-devel] [PULL 2/8] rdma: new QEMUFileOps hooks mrhines
2013-04-16 3:24 ` Paolo Bonzini
2013-04-16 4:44 ` Michael R. Hines
2013-04-16 2:44 ` [Qemu-devel] [PULL 3/8] rdma: export ram_handle_compressed() mrhines
2013-04-16 2:44 ` [Qemu-devel] [PULL 4/8] rdma: introduce capability for chunk registration mrhines
2013-04-16 4:50 ` Paolo Bonzini
2013-04-16 12:58 ` Eric Blake
2013-04-16 14:54 ` Michael R. Hines
2013-04-16 2:44 ` [Qemu-devel] [PULL 5/8] rdma: core rdma logic mrhines
2013-04-16 4:49 ` Paolo Bonzini
2013-04-16 6:09 ` Paolo Bonzini
2013-04-16 14:48 ` Michael R. Hines
2013-04-17 3:27 ` Michael R. Hines
2013-04-17 8:58 ` Paolo Bonzini
2013-04-17 15:59 ` Michael R. Hines
2013-04-17 16:48 ` Paolo Bonzini [this message]
2013-04-16 2:44 ` [Qemu-devel] [PULL 6/8] rdma: send pc.ram mrhines
2013-04-16 3:25 ` Paolo Bonzini
2013-04-16 2:44 ` [Qemu-devel] [PULL 7/8] rdma: print out throughput while debugging mrhines
2013-04-16 2:44 ` [Qemu-devel] [PULL 8/8] rdma: add documentation mrhines
2013-04-16 3:23 ` [Qemu-devel] [PULL 0/8] rdma: migration support Paolo Bonzini
2013-04-16 14:32 ` Anthony Liguori
2013-04-16 14:34 ` Paolo Bonzini
2013-04-16 15:42 ` Anthony Liguori
2013-04-16 14:52 ` Michael R. Hines
2013-04-16 14:53 ` Paolo Bonzini
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=516ED252.7090609@redhat.com \
--to=pbonzini@redhat.com \
--cc=abali@us.ibm.com \
--cc=aliguori@us.ibm.com \
--cc=gokul@us.ibm.com \
--cc=mrhines@linux.vnet.ibm.com \
--cc=mrhines@us.ibm.com \
--cc=mst@redhat.com \
--cc=owasserm@redhat.com \
--cc=qemu-devel@nongnu.org \
/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).