Versions Compared

Old Version 31

changes.mady.by.user ruoyu.ying

Saved on

compared with

New Version 32

changes.mady.by.user ruoyu.ying

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Reverted from v. 29

Overall design

Gliffy
nameSRIOV-modules
pagePin23


1. Scenario

Let us say, a site has three kinds of compute nodes with respect to SRIOV-NIC

...

3rd set does not contain any SRIOV NIC cards.

1.1 Openstack Config SRIOV

Openstack configuration:

  1. NIC configuration  refer to to https://docs.openstack.org/neutron/pike/admin/config-sriov.html

  2. Create flavors.
    Flavor1:

     $ openstack flavor create flavor1 --id auto --ram 512 --disk 40 --vcpus 4

     $ openstack flavor set flavor1 --property pci_passthrough:alias=NIC-sriov-1234-5678-physnet1:1

     $ openstack flavor set flavor1 --property pci_passthrough:alias=NIC-sriov-2345-6789-physnet2:1

     
    Flavor2:
     $ openstack flavor create flavor2 --id auto --ram 512 --disk 40 --vcpus 4

     $ openstack flavor set flavor2 --property pci_passthrough:alias=NIC-sriov-4321-8765:2


    Flavor3
     $ openstack flavor create flavor3 --id auto --ram 512 --disk 40 --vcpus 4

     

1.2 Mutli-cloud discovery

When it reads the flavors information from openstack site, if the pci_passthrough alias start with NIC-sriov, then it assumes that it is SRIOV NIC type.

...

As part of discovery, it populates the A&AI with two PCIe features for Flavor1.


hpa-feature=”pciePassthrough”,

...

Hpa-attribute-key

Hpa-attribute-value

pciVendorId

2345

pciDeviceId

6789

pciCount

1

interfaceType

SRIOV-NIC

providerNetwork

Physnet2

1.3 SO call OOF

SO will get pciVendorId, pciDeviceId and interfaceType from CSAR file, then call to OOF. OOF will response homing information to SO, SO don't interpret it and pass through it to Multi-cloud.

1.4 VF-C call OOF

VF-C will get pciVendorId, pciDeviceId and interfaceType from CSAR file, then call to OOF. OOF will response homing information to VF-C.

1.5 OOF Response

OOF will match the SRIOV information along with the constraint provided by Policy and add extra attributes inside the assignmentInfo data block when returning the response to SO and VF-C.

Sample looks like below.

"assignmentInfo":

[


    { "key":"locationId",
      "value":"DLLSTX1A"

},

{ "key":"locationType",
      "value":"openstack-cloud"

},

   

{ "key":"vimId",
      "value":"rackspace_DLLSTX1A"

},

{ "key":"oofDirectives",
      "value":{

        "directives":[

{

"vnfc_directives":[
               {
                  "vnfc_id":"

<ID of

<ID of VNFC>",
                  "directives":[
                     {
                        "directive_name":"

<Name of

<Name of directive,example

flavor_directive>",
                        "attributes":[
                           {
                              "attribute_name":"

<name of

<name of attribute,

such

as

flavor

label>",
                              "attribute_value":"

<value such as cloud specific

<value such as cloud specific flavor>"
                           }
                        ]
                     },
                     {
                        "directive_name":"

<Name of

<Name of directive,example

vnic-info>",
                        "attributes":[
                           {
                              "attribute_name":"

<name of

<name of attribute,

such

as

vnic-type>",
                              "attribute_value":"

<value such as

<value such as direct/normal>"
                           },
                           {
                              "attribute_name":"

<name of

<name of attribute,

such

as

provider

netweork>",
                              "attribute_value":"

<value such as

<value such as physnet>"
                           }
                        ]
                     }
                  ]
               }
            ]
         },
         {
            "vnf_directives":{
               "directives":[
                  {
                     "directive_name":"

<Name of

<Name of directive>",
                     "attributes":[
                        {
                           "attribute_name":"

<name of

<name of attribute>",
                           "attribute_value":"

<value>

<value>"
                        }
                     ]
                  },
                  {
                     "directive_name":"

<Name of

<Name of directive>",
                     "attributes":[
                        {
                           "attribute_name":"

<name of

<name of attribute>",
                           "attribute_value":"

<value >

<value >"
                        },
                        {
                           "attribute_name":"

<name of

<name of attribute>",
                           "attribute_value":"

<value >

<value >"
                        }
                     ]
                  }
               ]
            }
         }
      ]
   }

}

]    


For the newly added oofDirectives, we only return the vnfc part. For example: 

"vnfc_directives":

[

{

"vnfc_id":"",

"directives":[

{

"directive_name": "flavor_directive",

              "attributes":

[
                

{"attribute_name": "flavor_label_1", "attribute_value":"HPA.flavor"}

]

           },
          {

"directive_name": "vnic-info",
              

"attributes":

[
                    {"attribute_name": "vnic-type", "attribute_value":"direct"},
                    {"attribute_name":

"provider_network", "attribute_value":"physnet2"}
                ]
          }

]

}       

}       
]

It is worth noting that the vnic-type is converted from interfaceType in OOF.

...