On Thu, Mar 11, 2021 at 22:04, Sean Mooney <smooney@redhat.com> wrote:
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/libv...
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%20stat...)
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#L3... 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/a9fc746249cd34cb7cc594c0b4d74d8ddf... 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.
Both Stephen and I on board to continue reviewing the VDPA series further. I just did my review round this morning and the implementation looks good to me, the bug we see yesterday has been fixed. I have some minor comments, mostly cosmetic. I can review the ops blocking patch today and that will be the last functional patch in the series that needs to land. The reno patch can be merged later without risk. The functional tests also can be landed next week without risk. I know that Sean did testing with real hardware locally so I'm pretty confident about the series. So I'm OK with accepting the FFE request. If anybody has objection please reply. Cheers, gibi
regards sean.