On Wed, 2023-03-01 at 18:12 +0800, Simon Jones wrote:
Thanks a lot !!!
As you say, I follow https://docs.openstack.org/neutron/latest/admin/ovn/smartnic_dpu.html. And I want to use DPU mode. Not "disable DPU mode". So I think I should follow the link above exactlly, so I use vnic-type=remote_anaged. In my opnion, after I run first three command (which is "openstack network create ...", "openstack subnet create", "openstack port create ..."), the VF rep port and OVN and OVS rules are all ready. not at that point nothign will have been done on ovn/ovs
What I should do in "openstack server create ..." is to JUST add PCI device into VM, do NOT call neutron-server in nova-compute of compute node ( like call port_binding or something).
that will only happen after the port is bound to a vm and host. this is incorrect.
But as the log and steps said in the emails above, nova-compute call port_binding to neutron-server while running the command "openstack server create ...".
So I still have questions is: 1) Is my opinion right? Which is "JUST add PCI device into VM, do NOT call neutron-server in nova-compute of compute node ( like call port_binding or something)" .
no this is not how its designed. until you attach the logical port to a vm (either at runtime or as part of vm create) the logical port is not assocated with any host or phsical dpu/vf. so its not possibel to instanciate the openflow rules in ovs form the logical switch model in the ovn north db as no chassie info has been populated and we do not have the dpu serial info in the port binding details.
2) If it's right, how to deal with this? Which is how to JUST add PCI device into VM, do NOT call neutron-server? By command or by configure? Is there come document ? no this happens automaticaly when nova does the port binding which cannot happen until after teh vm is schduled to a host.
---- Simon Jones
Sean Mooney <smooney@redhat.com> 于2023年3月1日周三 16:15写道：
On Wed, 2023-03-01 at 15:20 +0800, Simon Jones wrote:
BTW, this link ( https://docs.openstack.org/neutron/latest/admin/ovn/smartnic_dpu.html) said I SHOULD add "remote_managed" in /etc/nova/nova.conf, is that WRONG ?
no its not wrong but for dpu smart nics you have to make a choice when you deploy either they can be used in dpu mode in which case remote_managed shoudl be set to true and you can only use them via neutron ports with vnic-type=remote_managed as descried in that doc
https://docs.openstack.org/neutron/latest/admin/ovn/smartnic_dpu.html#launch...
or if you disable dpu mode in the nic frimware then you shoudl remvoe remote_managed form the pci device list and then it can be used liek a normal vf either for neutron sriov ports vnic-type=direct or via flavor based pci passthough.
the issue you were havign is you configured the pci device list to contain "remote_managed: ture" which means the vf can only be consumed by a neutron port with vnic-type=remote_managed, when you have "remote_managed: false" or unset you can use it via vnic-type=direct i forgot that slight detail that vnic-type=remote_managed is required for "remote_managed: ture".
in either case you foudn the correct doc https://docs.openstack.org/neutron/latest/admin/ovn/smartnic_dpu.html neutorn sriov port configuration is documented here https://docs.openstack.org/neutron/latest/admin/config-sriov.html and nova flavor based pci passthough is documeted here https://docs.openstack.org/nova/latest/admin/pci-passthrough.html
all three server slightly differnt uses. both neutron proceedures are exclusivly fo network interfaces. https://docs.openstack.org/neutron/latest/admin/ovn/smartnic_dpu.html requires the use of ovn deployed on the dpu to configure the VF contolplane. https://docs.openstack.org/neutron/latest/admin/config-sriov.html uses the sriov nic agent to manage the VF with ip tools. https://docs.openstack.org/nova/latest/admin/pci-passthrough.html is intended for pci passthough of stateless acclerorators like qat devices. while the nova flavor approch cna be used with nics it not how its generally ment to be used and when used to passthough a nic expectation is that its not related to a neuton network.