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-attribute-key

hpa-attribute-value

numCpuSockets

{value:4}

numCpuCores

{value:4}

numCpuThreads

{value:8}

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-attribute-key

hpa-attribute-value

numVirtualCpu

{value:4}

virtualMemSize

{value:4, unit:”MB”}

HPA OVS DPDK Policy Example

dataProcessingAccelerationLibrary

ovsDpdk



hpa-capability-id="b369fd3d-0b15-44e1-81b2-6210efc6dffa",

hpa-feature=”ovsDpdk”,

architecture=”Intel64",

hpa-version=”v1”,

hpa-attribute-key

hpa-attribute-value

dataProcessingAccelerationLibrary

{value:”v12.1”}

“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-attribute-key

hpa-attribute-value

logicalCpuThreadPinningPolicy

{value:”prefer”}

logicalCpuPinningPolicy

{value:”dedicated”}

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-attribute-key

hpa-attribute-value

numaNodes

{value:2}

numaCpu-0

{value:[0,1]}

numaCpu-1

{value:[2,3,4,5]}

numaMem-0

{value:2, unit:”MB”}

numaMem-1

{value:4, unit:”MB”}

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-attribute-key

hpa-attribute-value

pciCount

{value: 1}

pciVendorId

{value: "1234"}

pciDeviceId{value: "5678"}
physicalNetwork

{value:"physnet1"}

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-attribute-key

hpa-attribute-value

pciCount

{value: 1}

pciVendorId

{value: "8086"}

pciDeviceId{value: "0443"}

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-attribute-key

hpa-attribute-value

diskSize

{value:4096, unit:”GB”}

ephemeralDiskSize

{value:160, unit:”GB”}

swapMemSize{value:8192, unit:”MB”}

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-attribute-key

hpa-attribute-value

instructionSetExtensions

{value:["AAA", "BBB"]}

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”,

hpa-attribute-key

hpa-attribute-value

memoryPageSize

{value:2, unit:”MB”}

  • No labels

9 Comments

  1. Huang Haibin

    I am working on “HPA CPU Pinning".

  2. 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.


                   


  3. Adolfo Perez-Duran

    Hi Ritu Sood

    A few items we need to review:

    1. dataProcessingAccelerationLibrary

    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.


    1. 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.


  4. 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

  5. Ruoyu Ying

    Hi Haibin(Huang Haibin), for the new feature 'sriovNICNetwork',  do we still need the hpa-attribute 'pci-count' ?

    1. Huang Haibin

      Yes, I think we need "pci-count".

  6. 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

    1. Ruoyu Ying

      Thanks Srini.

      Best Regards?
      Ruoyu