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