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.
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.
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
participants (4)
-
Aline Manera -
Christy Perez -
Crístian Viana -
Yu Xin Huo