8:43 p.m.
This patchset is a better functioning, but not final, version of the
topology logic. Aline asked that I send another version with details
for the UI will interact with the cpu_info API.
The flow will be:
- GET /host/cpu_info:
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
}
Note: I removed the cores_online and cores_present, and changed it
to just cores. I think the other was too much info.
- Based on that information, plus the host arch, the UI can display
- If host arch is Power:
- 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).
- 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.), but that will
get complicated with different types of processors, and also
be too tedious to use. So, unless someone objects,
I think the next best thing to do, is just slightly adjust the number
of vCPUs the user asked for in order to make sure that the number
is a legal number to use with a topology (since vCPUS must equal
sockets * cores * threads).
Note: See below return from get_rec_topology. If different than
what the user entered, this new vcpus should replace the number
entered by the user. If some kind of effect could be shown
when it's changed, that might be helpful.
- Else:
- Display a menu labeled Hyper-Threading, with only a checkbox labeled
HT.
Note: The same comments for vCPUS as above apply here. The number
maybe need to change based on the CPU capabilities.
- The user's selections from those fields is sent to the get_rec_topology
method, which will then return two values:
{'topology': {'sockets': sockets, 'cores': cores,
'threads': threads},
'vcpus': best_vcpus}
These values can then be used to create the template:
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}}}'
What doesn't work right now:
- Some error messages still need to be created.
- API doc needs to be added.
Christy Perez (1):
Parts to allow Kimchi to configure the cpu topology.
docs/API.md | 2 +
src/kimchi/API.json | 6 ++
src/kimchi/control/cpuinfo.py | 37 +++++++++
src/kimchi/control/host.py | 2 +
src/kimchi/i18n.py | 2 +
src/kimchi/model/cpuinfo.py | 175 ++++++++++++++++++++++++++++++++++++++++++
src/kimchi/model/host.py | 1 +
src/kimchi/model/templates.py | 16 +++-
8 files changed, 240 insertions(+), 1 deletion(-)
create mode 100644 src/kimchi/control/cpuinfo.py
create mode 100644 src/kimchi/model/cpuinfo.py
--
1.9.3