[Kimchi-devel] UI Mockup of SMT

[Christy Perez]

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 at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>
> 
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>