Open Stack

On Thu, Mar 11, 2021 at 22:04, Sean Mooney <smooney at 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/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.

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.
> 
> 
> 
> 
>