From: Bandan Das <bsd@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>,
Anthony Liguori <aliguori@us.ibm.com>,
Eduardo Habkost <ehabkost@redhat.com>,
Markus Armbruster <armbru@redhat.com>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v3] vl.c: Support multiple CPU ranges on -numa option
Date: Thu, 20 Jun 2013 12:02:07 -0400 [thread overview]
Message-ID: <jpgppvgg48w.fsf@redhat.com> (raw)
In-Reply-To: <51C303E7.0@redhat.com> (Paolo Bonzini's message of "Thu, 20 Jun 2013 15:30:15 +0200")
Paolo Bonzini <pbonzini@redhat.com> writes:
> Il 20/06/2013 15:26, Eduardo Habkost ha scritto:
>> On Thu, Jun 20, 2013 at 11:52:42AM +0200, Paolo Bonzini wrote:
>>> Il 20/06/2013 11:30, Igor Mammedov ha scritto:
>>>>>>>>>> So, basically the format seemed easier to work with if we are thinking
>>>>>>>>>> of using QemuOpts for -numa. Using -cpu rather than cpus probably
>>>>>>>>>> makes it less ambiguous as well IMO. However, it's probably not a good idea
>>>>>>>>>> if the current syntax is well established ?
>>>>>>
>>>>>> libvirt uses the "cpus" option already, so we have to keep it working.
>>>> Sure, we can leave it as it's now for some time while a new interface is
>>>> introduced/adopted. And than later deprecate "cpus".
>>>
>>> So, you used a new name because the new behavior of "-numa
>>> node,cpus=1-2,cpus=3-4" would be incompatible with the old.
>>
>> I don't think anybody uses "cpus=1-2,cpus=3-4" today, so I believe we
>> can change its behavior. The problem was to get agreement on the syntax
>> to represent multiple CPU ranges.
>
> Ok. I think almost everyone agreed on "cpus=1-2,cpus=3-4", which is
> basically what Bandan's patch does minus s/cpu/cpus/. It matches what
> already happens with other options (SLIRP), so it's hardly surprising.
Good, so should I spin a new version with "cpus" ?
Also note that this patch actually doesn't add any extra code to support
multiple cpus arguments. It all happens automatically as part of conversion to
QemuOpts. So, if we need to revisit the syntax later, we can always do that.
Bandan
> Let's go on with that.
>
> Paolo
>
>>> Personally I don't think that's a problem, but I remember a long
>>> discussion in the past. Igor/Eduardo, do you remember the conclusions?
>>
>> I don't remember seeing the discussion reach any conclusion,
>> unfortunately.
>>
next prev parent reply other threads:[~2013-06-20 16:02 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-18 20:09 [Qemu-devel] [PATCH v3] vl.c: Support multiple CPU ranges on -numa option Bandan Das
2013-06-19 11:42 ` Igor Mammedov
2013-06-19 13:26 ` Eduardo Habkost
2013-06-20 9:30 ` Igor Mammedov
2013-06-20 9:52 ` Paolo Bonzini
2013-06-20 11:34 ` Michael Tokarev
2013-06-20 13:02 ` Paolo Bonzini
2013-06-20 13:26 ` Eduardo Habkost
2013-06-20 13:30 ` Paolo Bonzini
2013-06-20 16:02 ` Bandan Das [this message]
2013-06-21 6:53 ` Wanlong Gao
2013-06-21 14:51 ` Bandan Das
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=jpgppvgg48w.fsf@redhat.com \
--to=bsd@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=armbru@redhat.com \
--cc=ehabkost@redhat.com \
--cc=imammedo@redhat.com \
--cc=pbonzini@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).