12:21 p.m.
On 13-11-2014 08:58, Yu Xin Huo wrote:
x86
Power(for SMT, I think it is single selection)
Even though I know it might make the code a little harder, I think it
would be better to display the HT field (on x86) as a checkbox element,
where the user can enable and disable quickly. A combo box is not
appropriate for on/off statuses. But I understand that it's easier
because of how SMT works on POWER, and you'd need a combo box anyway.
3:52 a.m.
1. Making it a combobox is not for the purpose to simplify coding, it is
for visual balance, for current kimchi UI style, you can imagine how a
checkbox looks there.
2. Please clarify below
http://lists.ovirt.org/pipermail/kimchi-devel/2014-November/008660.html
---- For below, do you mean that I should always display SMT1, SMT2,
SMT4 for the first 3, and for the last one, it will be
SMT[threads_per_core]? I wonder why only 4 options.
Display a menu labled SMT, with up to four check-boxes.
The check-boxes will be labeled SMT1, SMT2, SMT4, and SMT8.
The max SMT value displayed will be dependant upon
threads_per_core from above. The default checkbox should be the
greatest SMT value (e.g. SMT8).
---- For below, seems like you mean the CPUs should be limited to a
certain set of numbers, where to get this set of numbers.
Display the same box for CPUs as before. I had initially thought
about having a drop-down for CPUs instead of the empty field,
(with only legal vCPU amounts, like 1,2,4,8, etc.)
---- For below
curl -k -u user -X POST -H 'Content-Typ: application/json' -H 'Accept:
application/json' \
https://localhost:8001/templates -d'{"name": "test_topo",
"cdrom": "/isos/DVD_name.iso", \
"cpus":4, "cpu_info": {"topology": {"sockets":
1, "cores": 2, "threads":2}}}'
This is the content when create template, what content should be added
for 'SMT' or 'Hyper-threading' when saving a template.
On 11/14/2014 2:21 AM, Crístian Viana wrote:
On 13-11-2014 08:58, Yu Xin Huo wrote:
> x86
>
>
> Power(for SMT, I think it is single selection)
>
>
>
Even though I know it might make the code a little harder, I think it
would be better to display the HT field (on x86) as a checkbox
element, where the user can enable and disable quickly. A combo box is
not appropriate for on/off statuses. But I understand that it's easier
because of how SMT works on POWER, and you'd need a combo box anyway.
8:03 a.m.
On 11/14/2014 03:52 AM, Yu Xin Huo wrote:
1. Making it a combobox is not for the purpose to simplify coding, it
is for
visual balance, for current kimchi UI style, you can imagine how a checkbox
looks there.
2. Please clarify below
http://lists.ovirt.org/pipermail/kimchi-devel/2014-November/008660.html
---- For below, do you mean that I should always display SMT1, SMT2, SMT4 for
the first 3, and for the last one, it will be SMT[threads_per_core]? I wonder
why only 4 options.
I meant, if the host CPU has 4 threads/core, you'd give the
options of
SMT1, SMT2, SMT4. If it has 8, you'd give the options SMT1, SMT2, SMT4,
and SMT8, etc. And the default one should be the greatest one available.
Display a menu labled SMT, with up to four check-boxes.
The check-boxes will be labeled SMT1, SMT2, SMT4, and SMT8.
The max SMT value displayed will be dependant upon
threads_per_core from above. The default checkbox should be the
greatest SMT value (e.g. SMT8).
---- For below, seems like you mean the CPUs should be limited to a certain set
of numbers, where to get this set of numbers.
Display the same box for CPUs as before. I had initially thought
about having a drop-down for CPUs instead of the empty field,
(with only legal vCPU amounts, like 1,2,4,8, etc.)
Nope. I changed my
mind on that. Hopefully my latest patchset is more clear.
---- For below
curl -k -u user -X POST -H 'Content-Typ: application/json' -H 'Accept:
application/json' \
https://localhost:8001/templates -d'{"name": "test_topo",
"cdrom": "/isos/DVD_name.iso", \
"cpus":4, "cpu_info": {"topology": {"sockets":
1, "cores": 2, "threads":2}}}'
This is the content when create template, what content should be added for 'SMT'
or 'Hyper-threading' when saving a template.
You're right. For SMT, you'll only pass in 'threads.' My latest patchset
should have a better explanation.
On 11/14/2014 2:21 AM, Crístian Viana wrote:
> On 13-11-2014 08:58, Yu Xin Huo wrote:
>> x86
>>
>>
>> Power(for SMT, I think it is single selection)
>>
>>
>>
>
> Even though I know it might make the code a little harder, I think it would be
> better to display the HT field (on x86) as a checkbox element, where the user
> can enable and disable quickly. A combo box is not appropriate for on/off
> statuses. But I understand that it's easier because of how SMT works on POWER,
> and you'd need a combo box anyway.
_______________________________________________
Kimchi-devel mailing list
Kimchi-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel
4:47 p.m.
On 11/14/2014 08:03 AM, Christy Perez wrote:
On 11/14/2014 03:52 AM, Yu Xin Huo wrote:
> 1. Making it a combobox is not for the purpose to simplify coding, it is for
> visual balance, for current kimchi UI style, you can imagine how a checkbox
> looks there.
> 2. Please clarify below
>
> http://lists.ovirt.org/pipermail/kimchi-devel/2014-November/008660.html
>
> ---- For below, do you mean that I should always display SMT1, SMT2, SMT4 for
> the first 3, and for the last one, it will be SMT[threads_per_core]? I wonder
> why only 4 options.
I meant, if the host CPU has 4 threads/core, you'd give the options of
SMT1, SMT2, SMT4. If it has 8, you'd give the options SMT1, SMT2, SMT4,
and SMT8, etc. And the default one should be the greatest one available.
>
> Display a menu labled SMT, with up to four check-boxes.
> The check-boxes will be labeled SMT1, SMT2, SMT4, and SMT8.
> The max SMT value displayed will be dependant upon
> threads_per_core from above. The default checkbox should be the
> greatest SMT value (e.g. SMT8).
>
> ---- For below, seems like you mean the CPUs should be limited to a certain set
> of numbers, where to get this set of numbers.
>
> Display the same box for CPUs as before. I had initially thought
> about having a drop-down for CPUs instead of the empty field,
> (with only legal vCPU amounts, like 1,2,4,8, etc.)
Nope. I changed my mind on that. Hopefully my latest patchset is more clear.
>
> ---- For below
>
> curl -k -u user -X POST -H 'Content-Typ: application/json' -H 'Accept:
application/json' \
> https://localhost:8001/templates -d'{"name": "test_topo",
"cdrom": "/isos/DVD_name.iso", \
> "cpus":4, "cpu_info": {"topology":
{"sockets": 1, "cores": 2, "threads":2}}}'
>
>
> This is the content when create template, what content should be added for
'SMT'
> or 'Hyper-threading' when saving a template.
You're right. For SMT, you'll only pass in 'threads.' My latest patchset
should have a better explanation.
While making sure I've considered all cases...I've re-thought this a
tiny bit more, and found a spot I missed, and would like to have the UI
add an "Automatic" entry for SMT.
For an explanation, here's one such scenario:
Power8 = 8 threads/core (in normal mode).
A user wants 10 vcpus.
Since threads (for SMT) has to be 1, 2, 4, or 8, that doesn't align with
SMT.
The only wo valid topologies would be: sockets, cores, threads
= (1, 10, 1) (SMT1)
= (1, 5, 2) (SMT2)
Given that there are enough cores on the system to support the combination.
So, for the UI SMT dropdown, instead of the set of
[X] = 2^n for 0 > n <= log(threads_per_core, 2), it would be:
[X] = 2^n for 0 > n < log(threads_per_core, 2) such that n: {factors of
vcpu <= threads_per_core}
For the 10 vcpus example:
log(threads_per_core, 2) = log(8, 2) = 3
factors of 10 are n = {1, 2, 5, 10}, so only 1,2 are <= 3
But that is only valid for *even* vcpu values. A guest can only have an
odd # of vcpus if there are that many cores on the system. For example:
3 vcpus would be (1, 3, 1), 7 would be (1,7, 1), and so forth.
With so many ways for a user to mess up, it might be simpler to not even
force the passing of an SMT value. If one is chosen, an error back would
be acceptable since he/she deviated from the defaults.
This would also shift all the pre-validation into the backend where it
really belongs.
For users more accustomed to Power who want to chose a specific SMT
number, it will be much less likely that he/she enters a vCPU value that
doesn't make sense.
In the "Automatic" case, the GET for Power would also have threads=0
(like for x86).
A very small change for the UI from previous mockups.
>
>
> On 11/14/2014 2:21 AM, Crístian Viana wrote:
>> On 13-11-2014 08:58, Yu Xin Huo wrote:
>>> x86
>>>
>>>
>>> Power(for SMT, I think it is single selection)
>>>
>>>
>>>
>>
>> Even though I know it might make the code a little harder, I think it would be
>> better to display the HT field (on x86) as a checkbox element, where the user
>> can enable and disable quickly. A combo box is not appropriate for on/off
>> statuses. But I understand that it's easier because of how SMT works on
POWER,
>> and you'd need a combo box anyway.
>
>
>
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>
_______________________________________________
Kimchi-devel mailing list
Kimchi-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel
12:01 p.m.
On 11/14/2014 07:52 AM, Yu Xin Huo wrote:
1. Making it a combobox is not for the purpose to simplify coding, it
is for visual balance, for current kimchi UI style, you can imagine
how a checkbox looks there.
We could put the check box aside the CPU input box as they are related.
CPU [________________] [ ] Hyper Threading
2. Please clarify below
http://lists.ovirt.org/pipermail/kimchi-devel/2014-November/008660.html
---- For below, do you mean that I should always display SMT1, SMT2,
SMT4 for the first 3, and for the last one, it will be
SMT[threads_per_core]? I wonder why only 4 options.
Display a menu labled SMT, with up to four check-boxes.
The check-boxes will be labeled SMT1, SMT2, SMT4, and SMT8.
The max SMT value displayed will be dependant upon
threads_per_core from above. The default checkbox should be the
greatest SMT value (e.g. SMT8).
---- For below, seems like you mean the CPUs should be limited to a
certain set of numbers, where to get this set of numbers.
Display the same box for CPUs as before. I had initially thought
about having a drop-down for CPUs instead of the empty field,
(with only legal vCPU amounts, like 1,2,4,8, etc.)
---- For below
curl -k -u user -X POST -H 'Content-Typ: application/json' -H 'Accept:
application/json' \
https://localhost:8001/templates -d'{"name": "test_topo",
"cdrom": "/isos/DVD_name.iso", \
"cpus":4, "cpu_info": {"topology": {"sockets":
1, "cores": 2, "threads":2}}}'
This is the content when create template, what content should be added
for 'SMT' or 'Hyper-threading' when saving a template.
On 11/14/2014 2:21 AM, Crístian Viana wrote:
> On 13-11-2014 08:58, Yu Xin Huo wrote:
>> x86
>>
>>
>> Power(for SMT, I think it is single selection)
>>
>>
>>
>
> Even though I know it might make the code a little harder, I think it
> would be better to display the HT field (on x86) as a checkbox
> element, where the user can enable and disable quickly. A combo box
> is not appropriate for on/off statuses. But I understand that it's
> easier because of how SMT works on POWER, and you'd need a combo box
> anyway.
_______________________________________________
Kimchi-devel mailing list
Kimchi-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel
6:37 p.m.
Looks good!
The only comment I have is that hyper-threading has a hyphen.
Regards,
- Christy
On 11/13/2014 04:58 AM, Yu Xin Huo wrote:
x86
Power(for SMT, I think it is single selection)
_______________________________________________
Kimchi-devel mailing list
Kimchi-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel
3449
days inactive
3450
days old
6 comments
4 participants
participants (4)
-
Aline Manera -
Christy Perez -
Crístian Viana -
Yu Xin Huo