On 11/18/2014 03:52 PM, Aline Manera wrote:
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"
And if the name SMT is very important we could do:
Threads per core (SMT): [<combo box>]
> 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
>
_______________________________________________
Kimchi-devel mailing list
Kimchi-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel