7:52 p.m.
On 11/18/2014 02:47 AM, Christy Perez wrote:
1. UI calls GET host/cpuinfo
curl -k -u user -H 'Content-Type: application/json' \
-H 'Accept: application/json' https://localhost:8001/host/cpuinfo
{
"cores":2,
"threading_enabled":true,
"sockets":1,
"threads_per_core":2
}
2. UI displays appropriate title and checkboxes
- For both arches (based on Aline's suggestion),
include a checkbox that says, "Configure vCPU topology manually."
If checked, two fields appear, labeled, 'cores,' and 'threads.'
For the threads box, have another dropdown that's the same in
theory as the SMTX choices: a drop-down of 1, 2, 4, 8 (depending on
the threads_per_socket value).
Can the 'cores' box have a hover hint that lists the max?
Since sockets will never be more than one, let's list it as a static
placeholder (or leave it off completely).
Checking this box will make the CPU box inactive, and the CPU number
should now be calculated by the UI: CPUs = cores * threads (from the
new boxes).
- If that manual tickbox isn't selected:
- Display the same box for CPUs as before.
- Display a menu labled SMT (Power)/Hyper-Threads (x86) with up to five
selections:
Automatic, 1, 2, 4, 8.
The max SMT value displayed will be dependant upoon threads_per_core
from above. The default option should be 'Automatic.'
For 'Automatic,' send in '0' for the threads value (#3
below).
Otherwise, pass the threads selection value (#3 below).
Note: This is more architecture-agnostic. The only difference is the label.
I'm in favor of keeping SMT somewhere in the screen for Power, since
that
is how users traditionally think of this, and will look for it.
I think 2 ways to do the same think will let user confused.
So I'd say to go by the first approach (that works for both arch). In
this approach we can also setup the cores and threads values
automatically based on CPU and the best SMT option.
Example:
On Power8:
- Disable vCPU field
- Enable/display cores and threads with the best options and update the
vCPU field by doing cores * threads.
CPU number: 16
[x] Configure vCPU topology manually
Cores: 2
Threads: 8
And if user agrees he just needs to select "Save"
3. UI calls POST template with threads value set to '0' (x86)
or SMTX (Power)
Note that vcpus is still optional, so no change in how that's handled needs
to be done.
$ curl -k -u user -X POST -H 'Content-Type: application/json' -H 'Accept:
application/json' https://localhost:8001/templates -d'{"name":
"test_auto_topo", "cdrom":
"/home/iso-pool/Fedora-Live-Desktop-x86_64-20-1.iso", "cpu_info":
{"topology": {"threads":0}}}'
{
"cpus":1,
"cpu_info":{
"topology":{
"cores":1,
"threads":1,
"sockets":1
}
},
"graphics":{
"type":"vnc",
"listen":"127.0.0.1"
},
"cdrom":"/home/iso-pool/Fedora-Live-Desktop-x86_64-20-1.iso",
"networks":[
"default"
],
"icon":"images/icon-fedora.png",
"os_distro":"fedora",
"name":"test_auto_topo",
"disks":[
{
"index":0,
"size":10
}
],
"invalid":{},
"os_version":"20",
"storagepool":"/storagepools/default",
"memory":1024,
"folder":[]
}
Christy Perez (1):
Parts to allow Kimchi to configure the cpu topology.
docs/API.md | 28 ++++++
src/kimchi/API.json | 11 +--
src/kimchi/control/cpuinfo.py | 37 ++++++++
src/kimchi/control/host.py | 2 +
src/kimchi/i18n.py | 6 +-
src/kimchi/model/cpuinfo.py | 215 ++++++++++++++++++++++++++++++++++++++++++
src/kimchi/model/host.py | 2 +-
src/kimchi/model/templates.py | 25 +++--
8 files changed, 309 insertions(+), 17 deletions(-)
create mode 100644 src/kimchi/control/cpuinfo.py
create mode 100644 src/kimchi/model/cpuinfo.py