Refer wiki page: https://wiki.onap.org/display/DW/Policy+Specification+and+Retrieval+for+OOF
Policy | Attributes | hpa-feature | Tosca Mapping | Openstack Mapping | AAI representation (Eg:) | ||||||||||||
HPA CPU Topology Policy Example | numCpuSockets numCpuCores numCpuThreads | cpuTopology | hw:cpu_sockets, hw:cpu_cores, hw:cpu_threads, | hpa-capability-id="a369fd3d-0b15-44e1-81b2-6210efc6dff8", hpa-feature=”cpuTopology”, architecture=”generic", hpa-version=”v1”,
| |||||||||||||
HPA Basic Capabilities Policy Example | numVirtualCpu virtualMemSize | basicCapabilities | virtual_cpu#num_virtual_cpu virtual_memory#virtual_mem_size | vcpus, ram | hpa-capability-id="b369fd3d-0b15-44e1-81b2-6210efc6dff9", hpa-feature=”basicCapabilities”, architecture=”generic", hpa-version=”v1”,
| ||||||||||||
HPA OVS DPDK Policy Example | dataProcessingAccelerationLibrary | ovsDpdk | hpa-capability-id="b369fd3d-0b15-44e1-81b2-6210efc6dffa", hpa-feature=”ovsDpdk”, architecture=”Intel64", hpa-version=”v1”,
| ||||||||||||||
“HPA CPU Pinning Policy Example | logicalCpuThreadPinningPolicy logicalCpuPinningPolicy | cpuPinning | hw:cpu_thread_policy hw:cpu_policy | hpa-capability-id="c369fd3d-0b15-44e1-81b2-6210efc6dffa", hpa-feature=”cpuPinning”, architecture=”generic", hpa-version=”v1”,
| |||||||||||||
HPA NUMA Policy Example | numaNodes numaCpu-N numaMem-N | numa | hw:numa_nodes hw:numa_cpus:N hw:numa_mem:N | hpa-capability-id="c369fd3d-0b15-44e1-81b2-6210efc6dffa", hpa-feature=”numa”, architecture=”generic", hpa-version=”v1”,
| |||||||||||||
HPA SriovNICNetwork Policy Example | pciCount pciVendorId pciDeviceId | SriovNICNetwork | virtual_network_interface_requirements#network_interface_requirements#interfaceType virtual_network_interface_requirements#nic_io_requirements#pciVendorId virtual_network_interface_requirements#nic_io_requirements#pciDeviceId virtual_network_interface_requirements#nic_io_requirements#pciNumDevices virtual_network_interface_requirements#nic_io_requirements#physicalNetwork? | sriov_nic=sriov-nic-<vendor>-<Vendor ID>-<Device ID>-physicalNetwork:COUNT It is expected thatOpenstackadministrator creates alias that stars with sriov and put the vendor ID, device ID. Example: Assume that there are two SRIOV-NIC cards supported by a region, Intel and Mellanox. Examples: sriov-nic-intel-1234-5678-physnet1:1 sriov-nic-mellanox-2345-6543-physnet1:1 | hpa-capability-id="ty53fd3d-0b15-11w4-81b2-6210efc6dff9", hpa-feature=”sriovNICNetwork”, architecture=”intel64", hpa-version=”v1”,
| ||||||||||||
HPA PCIe Passthrough Policy Example | pciCount pciVendorId pciDeviceId | pciePassthrough | virtual_network_interface_requirements#network_interface_requirements#interfaceType virtual_network_interface_requirements#nic_io_requirements#pciVendorId virtual_network_interface_requirements#nic_io_requirements#pciDeviceId virtual_network_interface_requirements#nic_io_requirements#pciNumDevices | pci_passthrough:alias=ALIAS:COUNT Openstack administrator is expected to create ALIAS as <aliasName>-<deviceType>-<architecture>-<PCIe vendor ID in Hex>-<PCIe device ID> QuickAssist example: "mycrypto-qat-intel-8086-0443" | hpa-capability-id="f453fd3d-0b15-11w4-81b2-6210efc6dff9", hpa-feature=”pciePassthrough”, architecture=”intel64", hpa-version=”v1”,
| ||||||||||||
HPA Local Storage Policy Example | diskSize ephemeralDiskSize swapMemSize | localStorage | disk swap | hpa-capability-id="u456fd3d-0b15-90r4-81b2-6210efc6dff9", hpa-feature=”localStorage”, architecture=”generic", hpa-version=”v1”,
| |||||||||||||
HPA CPU Instruction Set Extensions Policy Example | instructionSetExtensions | instructionSetExtensions | hw:capabilities:cpu_info:features | hpa-capability-id="c369fd3d-0b15-44e1-81b2-6210efc6dffa", hpa-feature=”instructionSetExtensions”, architecture=”Intel64", hpa-version=”v1”,
| |||||||||||||
HPA Huge Pages Policy Example | memoryPageSize | hugePages | virtual_memory#vdu_memory_requirements#memoryPageSize | hw:mem_page_size values can be ANY, 4KB, 2MB, 1GB How to handle large, small, any from openstack? if the hw:mem_page_size is an integer it is assumed the unit is in KB The deafult value for small page is 4k, for large page is 2M or 1G(recommended value 2M), for any page, libvirt will firstly to try to find large pages, if failed then will fall back to small pages. so it's suggest do not support any page in current release version | hpa-capability-id="e769fd3d-0b15-77b3-81b2-6210efc6dffa", hpa-feature=”hugePages”, architecture=”generic", hpa-version=”v1”,
|
9 Comments
Huang Haibin
I am working on “HPA CPU Pinning".
libo zhu
hello, RItu,
for the instructionSetExtensions (HPA CPU Instruction Set Extensions Policy Example), its name differs with that defined in TOSCA modelling Supported HPA Capability Requirements(DRAFT), whose name is instructionSetRequirements.
Adolfo Perez-Duran
Hi Ritu Sood
A few items we need to review:
Because the "dataProcessingAccelerationLibrary" is a library (software), it is not a hardware capability. Therefore ovsDpdk shouldn't be specified as an hpaFeature requirement.
2. cpuInstructionSetExtensions
cpuInstructionSetExtensions are available for most hardware (cpu) architectures. To account for this, we should use a "generic" hardwareArchitecture and add a prefix to the extensions. OpenStack has faced this problem (os-traits) and they have come up with prefixes. What do think about adopting the similar prefixes (e.g. HW_CPU_X86_SGX)?
3. sgx
sgx is a vendor-specific instruction set extension, shouldn't it treated as such. See item 2 above.
Srinivasa Addepalli
Ritu and all are very busy in finishing up the coding for HPA and let me try to address the questions.
On OVSDPDK being a software feature : HPA is new name for EPA. H was one of the problems I had, but I was told that we had to move on to avoid time in deciding the name. All VMM platform capabilities (software or hardware or firmware) are represented as part of HPA. For all practical purposes, you can imagine this as EPA.
On cpuInstructionSetExtensions : That is one option you suggested. But for uniform sake with respect to other HPA capabilities, we just want to keep that uniform method.
On Sgx: SGX is much more than just instruction set extension. Enclave memory size and public key hash are also part of SGX capabilities. Hence, it is made as separate HPA capability.
Ruoyu Ying
Hi Alex(Alexander Vul) and Ritu(Ritu Sood), I found there's a another page in the wiki which also displays the HPA schema(Policy Specification and Retrieval for OOF). However, the schema for the hpa capability 'pciePassthrough' is different from here. And i'm worried about that if the policy team creates policies according to that schema, there will be a mismatch inside OOF. So which page should we refer to ?
Thanks.
Ruoyu
Ruoyu Ying
Hi Haibin(Huang Haibin), for the new feature 'sriovNICNetwork', do we still need the hpa-attribute 'pci-count' ?
Huang Haibin
Yes, I think we need "pci-count".
Srinivasa Addepalli
Yes. It should have pci-count also.
Also, from openstack perspective, we expect following syntax:
We argree that it will not be host aggregate after quite a bit of discussion before.
It would be of the form: pci_passthrough:alias=ALIAS:COUNT
Where ALIAS is of form: sriov-device-<name>-<Vendor ID>-<Device ID>-<providernet>
For example: pci_passthrough:alias=sriov-device-intelnic-1234-5678-physnet1:2
Srini
Ruoyu Ying
Thanks Srini.
Best Regards?
Ruoyu