[Nova][FFE] libvirt vdpa support

Sean Mooney smooney at redhat.com
Thu Mar 11 22:04:36 UTC 2021


Hi everyone
its that time again where feature are almost ready but not quite.
vDPA (vHost data path acceleration) is an option kernel device offload api
that allows virtio complient software devices such as a virtio net interface to be
offloaded to a software or hardware acclerator such as a nic.
the full detail can be found in the spec: https://specs.openstack.org/openstack/nova-specs/specs/wallaby/approved/libvirt-vdpa-support.html

The series is up for review and gibi and stephen have been activly reviewing it over the last few day.
https://review.opendev.org/q/topic:%22vhost-vdpa%22+(status:open%20OR%20status:merged)

while the majority of the code now has +2s it wont be approved before the end of the day so i am formal asking for
a feature freeze exception to allow an addtional day or to finalise the feature.

the current status of the seriese id that there is one bug related to claiming pci device and marking the parent as unavaiable
and claiming the parent and marking the child VF/VDPA devices as unavaiable.
i have adressed this locally and will be pushing a patch to adress that later this evening once i add unit tests for thoes
edgecaes.

there is one patch that is pendeing to block unsupported lifecycle operation which i will be writing tomorrow.
that final patch will also document them both in a release note and in the api-guide.

in the evnet the full seriese is not deamed to be ready in time i have also written seperate patch to block booting vms with VDPA ports
now that neutron supports it but nova does not, https://review.opendev.org/c/openstack/nova/+/780065 if we do not merge the full serise
i would like to ask that we merge teh first 3 patches.

openstack/nova: master: block vm boot with vdpa ports
openstack/nova: master: objects: Add 'VDPA' to 'PciDeviceType'
openstack/nova: master: add constants for vnic type vdpa 

the reason for block patch is that now that neutron support vnic-type vdpa i belive its possibel to create a port of that type
and for nova to boot a vm however it will not actully use vdpa. i belvie it will take this else branch
https://github.com/openstack/nova/blob/master/nova/network/os_vif_util.py#L349-L357 and result in the vm booting with a stansard ovs
prot as if it was vnic-type=normal which will be confusing to debug since you were expecting to get hardware offloaed
ovs but just got a standard ovs port instead without hardware offloads. operators can also block vnic-type vdpa in the neutron config.
https://github.com/openstack/neutron/blob/a9fc746249cd34cb7cc594c0b4d74d8ddf65bd46/neutron/conf/plugins/ml2/drivers/openvswitch/mech_ovs_conf.py#L21-L37
but i think the nova solution is nicer since it does not require them to update there configs if this feature is not complted in Wallaby.

i do belive we can complete this feature with only a small amount of addtional work
and can continue to add more testing and lifecycle operations next cycle.
stephen has submited https://review.opendev.org/c/openstack/nova/+/780112 to start extending the functional
test framework to emulate vdpa devices so that we can harden the validation in the futrue via functional tests
in addtion to the existing unit test coverage. i have not reviewed it yet so cant say how long that will take
but i think that is something we can work and ensure it merged early next cycle if its not completed early next week.

regards
sean.







More information about the openstack-discuss mailing list