Hi, Port-resource-request (see: https://docs.openstack.org/api-ref/network/v2/index.html#port-resource-reque... ) is a read-only (and admin-only) field of ports, which is filled based on the agent heartbeats. So now there is now polling of agents or similar. Adding extra "overload" to this mechanism, like polling cyborg or similar looks something out of the original design for me, not to speak about the performance issues to add - API requests towards cyborg (or anything else) to every port GET operation - store cyborg related information in neutron db which was fetched from cyborg (periodically I suppose) to make neutron able to fill port-resource-request. Regards Lajos Sean Mooney <smooney@redhat.com> ezt írta (időpont: 2020. máj. 28., Cs, 16:13):
Hi all,
In cyborg pre-PTG meeting conducted last week[0],shaohe from Intel introduced SmartNIC support integrations,and we've reached some initial agreements:
The workflow for a user to create a server with network acceleartor(accelerator is managed by Cyborg) is:
1. create a port with accelerator request specified into binding_profile field NOTE: Putting the accelerator request(device_profile) into binding_profile is one possible solution implemented in our POC.
On Thu, 2020-05-28 at 20:50 +0800, yumeng bao wrote: the binding profile field is not really intended for this.
https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/definit... its intended to pass info from nova to neutron but not the other way around. it was orgininally introduced so that nova could pass info to the neutron plug in specificly the sriov pci address. it was not intended for two way comunicaiton to present infom form neutron to nova.
we kindo of broke that with the trusted vf feature but since that was intended to be admin only as its a security risk in a mulit tenant cloud its a slightl different case. i think we should avoid using the binding profile for passing info form neutron to nova and keep it for its orginal use of passing info from the virt dirver to the network backend.
Another possible solution,adding a new attribute to port object
binding_profile, is discussed in shanghai Summit[1]. This needs check with neutron team, which neutron team would suggest? from a nova persepctive i would prefer if this was a new extention.
for cyborg specific use instead of using the binding profile is admin only by default so its not realy a good way to request features be enabled. you can use neutron rbac policies to alther that i belive but in genral i dont think we shoudl advocate for non admins to be able to modify the binding profile as they can break nova. e.g. by modifying the pci addres. if we want to supprot cyborg/smartnic integration we should add a new device-profile extention that intoduces the ablity for a non admin user to specify a cyborg device profile name as a new attibute on the port.
the neutron server could then either retirve the request groups form cyborg and pass them as part of the port resouce request using the mechanium added for minium bandwidth or it can leave that to nova to manage.
i would kind of prefer neutron to do this but both could work.
2.create a server with the port created
Cyborg-nova-neutron integration workflow can be found on page 3 of the
slide[2] presented in pre-PTG.
And we also record the introduction! Please find the pre-PTG meeting
vedio record in [3] and [4], they are the same,
just for different region access.
[0] http://lists.openstack.org/pipermail/openstack-discuss/2020-May/014987.html [1]https://etherpad.opendev.org/p/Shanghai-Neutron-Cyborg-xproj [2]pre-PTG slides:https://docs.qq.com/slide/DVm5Jakx5ZlJXY3lw [3]pre-PTG vedio records in Youtube: https://www.youtube.com/watch?v=IN4haOK7sQg&feature=youtu.be [4]pre-PTG vedio records in Youku:
Regards， Yumeng