<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; ">
<div>Hi Yongli,</div>
<div><br>
</div>
<div>In today's IRC meeting, we discussed this a little bit. I think the answer probably lies in the definition of the PCI request. In the current implementation of _translate_alias_to_requests(), a new property (assume it's called requestor_id) maybe added
 to the PCI request. And this is how it works:</div>
<div>           -- add a requestor_id to the request spec, and return it to the caller</div>
<div>           -- when a device is allocated, a mapping requester_id to the pci device can be established </div>
<div>           -- the requestor later can retrieve the device by calling something like get_pci_device(requestor_id)</div>
<div><br>
</div>
<div>The requestor id could be a UUID that is generated by the python uuid module. </div>
<div><br>
</div>
<div>In the neutron SRIOV case, we need to create a PCI request per nic (or per requested_network). Therefore, the generic PCI may provide an API so that we can do so. Such API may look like:</div>
<div>              create_pci_request(count, request_spec), The request_spec is key value pairs. It returns a requestor_id.</div>
<div><br>
</div>
<div>Also if PCI flavor API is available later, I guess we can have an API like:</div>
<div>              create_pci_request_from_pci_flavor(count, pci_flavor). It returns a requestor_id as well.</div>
<div><br>
</div>
<div>Let me know what you think. </div>
<div><br>
</div>
<div>thanks,</div>
<div>Robert</div>
</body>
</html>