|
|
| (43 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| − | | + | merge back to: |
| − | ===API for whitelist===
| + | https://wiki.openstack.org/wiki/PCI_passthrough_SRIOV_support |
| − | not only the whitelist, the alias API also meaningful for administrator's pespective. the horizon could utilized the alias db to find what kind of device is avaliable to the tenants, and these configration more reasonable in form of API.
| |
| − | | |
| − | white list/ alias on demand is all some kind of (k, v) pairs, PCI API can exploit this to achive high flexibility.
| |
| − | | |
| − | and the group key configration is kind of policy for PCI and won't change rapidly, it's hould stay in the config file.
| |
| − | | |
| − | ===Use cases ===
| |
| − | | |
| − | ====admin inspect PCI devices (discuss)====
| |
| − | there is 2 method to implemt inspect.
| |
| − | # via database
| |
| − | currently pci device in the databse is after filter, if want inpect the deive on node, we should let all device going in to database. so problem is db will too large then eventually slow down query, became a scale problem. another problem is whitelist take effective the libvirt layer not in compute node (pci traker), this becuase same thing, reduce un-necessary infomation.
| |
| − |
| |
| − | # via RPC call
| |
| − | for inspect one node, use RPC call to get reulst from a node, show it to admin. this need investigate more.
| |
| − | | |
| − | ====admin create global groups ====
| |
| − | say data center have some identical hosts with same configration, so admin know the address for same device will have same address, then amdin want group the address '0000:01:00:7' and '0000:01:01:7' to a group say 'QucikAssist'
| |
| − | | |
| − | nova pci-config white-list create 'description'
| |
| − | we get id of this white-list, say 01
| |
| − | nova pci-config white-list 01 update group 'QuickAssist'
| |
| − | nova pci-config white-list 01 update address '0000:01:01:7'
| |
| − | nova pci-config white-list 01 update address '0000:01:00:7'
| |
| − | | |
| − | these cmd then convert to API call:
| |
| − | create/white-list/
| |
| − | udpate/white-list/01
| |
| − | udpate/white-list/01
| |
| − | udpate/white-list/01
| |
| − | | |
| − | with corresponding data:
| |
| − | { 'group':'QuickAssist'}
| |
| − | { 'adress':'0000:01:01:7'}
| |
| − | { 'adress':'0000:01:00:7'}
| |
| − | | |
| − | and you can create the white list in one cmd:
| |
| − | nova pci-config white-list create description 'xx' address '0000:01:00:7', '0000:01:01:7' group ''QuickAssist'
| |
| − | the API call then will be :
| |
| − | create/white-list/
| |
| − | with data:
| |
| − | { 'group':'QuickAssist', 'adress':'0000:01:01:7', 'adress':'0000:01:00:7', 'description': "xxx"}
| |
| − | | |
| − | | |
| − | ====nova pci-list node_id ====
| |
| − | ( this API is covered by another bp(list it here for a full picture view): https://blueprints.launchpad.net/nova/+spec/pci-api-support )
| |
| − | | |
| − | ====admin configures flavours that add PCI devices from a specific group====
| |
| − | | |
| − | ====user requests SRIOV====
| |
| − | or other PCI passthrough with similar thing (I want to see what data is stored in neutron vs nova here)
| |
| − | | |
| − | | |
| − | ====transite config file to API ====
| |
| − | # the config file for alias and whitelist defination is going to deprecated.
| |
| − | # if database is not NULL , configration is ommit and given deprecated warning.
| |
| − | # if database is NULL, config if read from the file, also given a deprecated notice, which will be remove start from next release.
| |
| − | | |
| − | with this solution, we move pci config from file to API.
| |
| − | | |
| − | ===DB for pci configration===
| |
| − | talbe: pci_config{
| |
| − | id
| |
| − | compute_node_id
| |
| − | object : whitelist/alias/group on demand
| |
| − | key
| |
| − | value
| |
| − | value_type: string, RE, list # for further enhancement
| |
| − | }
| |
| − | | |
| − | alias and on-demand group key is global.
| |
| − | | |
| − | DB API：
| |
| − | pci_config_get(context, obj_name):
| |
| − | | |
| − | pci_config_get_by_node(context, obj_name, node_id):
| |
| − | | |
| − | pci_config_update(context, obj_name, node_id, vlaues):
| |
| − | update the one object one time, ie, the white list on host "A": pci_config_update(context, 'whitelist', "A", {"vendor_id":"v1", "proudect_id":"p1", "address":"a1" }):
| |
| − | | |
| − | ===PCI releated Objects===
| |
| − | Objects: white list/ alias/ group keys(on demand grop)
| |
| − | objects property: sets of k,v
| |
| − |
| |
| − | ===API interface===
| |
| − | config-object-name: whitelist/alias/group
| |
| − | | |
| − | GET/v2/{tenant_id}/os-pci-config
| |
| − | show the pci configraion objects name.
| |
| − | {"pci_config": ['alias', 'whitelist', 'group']}
| |
| − | | |
| − | GET/v2/{tenant_id}/os-pci-config/{config-object-name}
| |
| − | show the pci configraion object's detail
| |
| − | i.e {config-object-name} is pci_alias:
| |
| − | {"pci_alias": [{'product_id':'8086', 'group':'nic-g1', 'compute-node-id':""}]}
| |
| − |
| |
| − | GET/v2/{tenant_id}/os-pci-config/{config-object-name}/{compute-node-id'}
| |
| − | show the pci configraion object's detail
| |
| − | i.e {config-object-name} is pci_whitelist:
| |
| − | {"pci_whitelist": {'product_id':'8086', 'group':'nic-g1', 'compute-node-id':"3"}}
| |
| − | | |
| − | | |
| − | PUT/v2/{tenant_id}/os-pci-config/{config-object-name}/{compute-node-id}
| |
| − | ie. i.e {config-object-name} is pci_whitelist:
| |
| − | {"pci_whitelist": {'product_id':'8086', 'address':'a1' , 'group':'nic-g1'}}
| |
| − | PUT/v2/{tenant_id}/os-pci-config/{config-object-name}/
| |
| − | change a global configration.
| |
| − |
| |
| − | DELETE/v2/{tenant_id}/os-pci-config/{config-object-name}/{compute_node_id}
| |
| − | DELETE/v2/{tenant_id}/os-pci-config/{config-object-name}/
| |
| − | | |
| − | UPDATE//v2/{tenant_id}/os-pci-config/{config-object-name}/
| |
| − | UPDATE//v2/{tenant_id}/os-pci-config/{config-object-name}/{compute_node_id}
| |
| − | make config 'config-object-name' take effect.
| |
