| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-11-16 | |||
| 15:14:18 | sean-k-mooney | dmitriis: technicaly the tags are defiend to be of type String | |
| 15:14:31 | sean-k-mooney | so its a dict of string to string | |
| 15:15:12 | sean-k-mooney | Adri2000: ack the reason i asked is apparently the lockign behavior is differnt in qemu for raw vs qcow | |
| 15:15:16 | dmitriis | sean-k-mooney: ack | |
| 15:17:26 | sean-k-mooney | dmitriis: https://github.com/openstack/nova/blob/master/nova/pci/devspec.py#L262-L263 | |
| 15:18:27 | dmitriis | sean-k-mooney: yep, makes sense | |
| 15:18:51 | dmitriis | sean-k-mooney: btw, the ovn-vif repo is now up under ovn-org https://github.com/ovn-org/ovn-vif | |
| 15:19:06 | sean-k-mooney | yes i saw your comment | |
| 15:19:10 | sean-k-mooney | just looking at the code | |
| 15:19:17 | dmitriis | ack | |
| 15:19:44 | sean-k-mooney | am i right in assuming we do not want to allow these device to be used for flavor based pci passthouhg | |
| 15:20:38 | dmitriis | sean-k-mooney: yes, they won't be of much use without being plugged appropriately. Not the VFs at least. | |
| 15:21:00 | sean-k-mooney | ya | |
| 15:21:11 | sean-k-mooney | im wondering if we should explictly block that | |
| 15:21:44 | sean-k-mooney | unfortunetly i dont see a trivial way to do that | |
| 15:22:05 | sean-k-mooney | although we might already do that | |
| 15:22:20 | dmitriis | sean-k-mooney: I guess we could exclude devices from search results if remote_managed is present but not requestedd | |
| 15:22:46 | sean-k-mooney | yep | |
| 15:22:58 | sean-k-mooney | i was just going to provide an exmaple | |
| 15:23:04 | sean-k-mooney | we do this in other cases already | |
| 15:23:33 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/pci/stats.py#L411-L433 | |
| 15:23:46 | sean-k-mooney | That filteres out PF if you did not ask for one | |
| 15:24:08 | sean-k-mooney | dmitriis: so you can copy past https://github.com/openstack/nova/blob/master/nova/pci/stats.py#L520-L535 | |
| 15:24:27 | sean-k-mooney | and then add a new function that will filter out remote managed device if not requested | |
| 15:24:49 | dmitriis | sean-k-mooney: https://review.opendev.org/c/openstack/nova/+/812111/3/nova/network/neutron.py#2295 | |
| 15:25:00 | sean-k-mooney | i did this recently when i added support for vdpa https://github.com/openstack/nova/blob/master/nova/pci/stats.py#L540 | |
| 15:25:01 | dmitriis | actually, I'm explicitly passing remote_managed=False | |
| 15:25:28 | sean-k-mooney | that wont work | |
| 15:25:55 | dmitriis | sean-k-mooney: even with this? https://review.opendev.org/c/openstack/nova/+/812111/3/nova/pci/stats.py#111 | |
| 15:25:58 | sean-k-mooney | it will break existing deploymetn on upgrade as there existing device wont have remote_managed=False | |
| 15:26:07 | sean-k-mooney | and it woudl only apply for pci recuts form ports | |
| 15:26:52 | sean-k-mooney | dmitriis: that would work but we might end up doign a data migration of all existing rows | |
| 15:27:34 | sean-k-mooney | dmitriis: ok we can review this as part of the code review rather then the spec. | |
| 15:27:51 | sean-k-mooney | im just finsihing reading it now and ill approve it shortly | |
| 15:27:52 | dmitriis | sean-k-mooney: ack, I am open to adding a filter as you suggested | |
| 15:28:35 | sean-k-mooney | either would work but one involes updateing every row in the pci device tabel with remote_managed=false :) | |
| 15:28:48 | dmitriis | right, I would certainly like to avoid introducing a change that would break with a stale state in PCI stats | |
| 15:28:50 | sean-k-mooney | the important thing is there is not a gap in the design | |
| 15:28:55 | dmitriis | agreed | |
| 15:43:38 | sean-k-mooney | dmitriis: ok i captured some of my tought in this converstaion in the spec but +2 +w from me | |
| 15:45:12 | sean-k-mooney | dmitriis: feel free to ping me to review the implemetaion too. i do not have +2 right on the code repo but ill try and spend some time reviewing it end to end next week | |
| 15:46:14 | dmitriis | sean-k-mooney: tyvm. I'll try to get the code updated with some of the latest changes by then. Still have to extend func tests to cover more cases but there are some already. | |
| 15:47:03 | dmitriis | sean-k-mooney: speaking of other lifecycle operations, I've spent some time looking at the recent VF hot-plug/unplug changes so I may revisit some of the unsupported operations at a later point | |
| 15:47:14 | bauzas | reminder : nova weekly meeting starts in 13 mins here in this #chan | |
| 15:47:33 | dmitriis | maybe we can actually make things like cold migration work, just need to review that further | |
| 15:47:45 | sean-k-mooney | ack | |
| 15:48:09 | sean-k-mooney | dmitriis: it might just work | |
| 15:48:29 | sean-k-mooney | there is very littel in the nova side that will need to be updated | |
| 15:48:37 | sean-k-mooney | also for the live migration | |
| 15:48:46 | dmitriis | sean-k-mooney: yes, we might need to document the need for extra slots to be added via the new config | |
| 15:49:05 | dmitriis | https://review.opendev.org/c/openstack/nova/+/545034/16/nova/conf/libvirt.py | |
| 15:49:13 | sean-k-mooney | dmitriis: that is really only need for q35 | |
| 15:49:26 | sean-k-mooney | and we already have a config to add extra slots in that case | |
| 15:49:47 | sean-k-mooney | yep that one | |
| 15:49:50 | dmitriis | ack | |
| 15:50:18 | sean-k-mooney | the pc machine type ahs 24 or 32 pci slot by default | |
| 15:50:47 | sean-k-mooney | for q35 the defautl behavior is to allocation all that are required for your vm +1 free for hotplug | |
| 15:51:07 | sean-k-mooney | oh... | |
| 15:51:26 | sean-k-mooney | there might be a bug in sriov live migration with q35 | |
| 15:52:22 | dmitriis | From the guest OS perspective, the PCI addressing is tied to the virtual PCI topology. Hopefully it is consistent across migration so that device naming doesn't change for the guest while the MAC is reprogrammed anyway. | |
| 15:52:26 | sean-k-mooney | i did most of my testing with pc and when i tested with q35 i dont know if i tested with more then one sriov nic | |
| 15:52:58 | sean-k-mooney | dmitriis: we dont gaurntee ti will be | |
| 15:53:07 | sean-k-mooney | so it might change | |
| 15:53:45 | dmitriis | sean-k-mooney: ah, good to know. Changing PCI addresses will change persistent device names tied to PCI addresses. | |
| 15:54:12 | sean-k-mooney | yes the way around that is to leverage device role tagging | |
| 15:54:39 | sean-k-mooney | but really we want qemu/kvm/nvidia to finish implemeitn live migration support for vdpa | |
| 15:54:48 | sean-k-mooney | so that we can just leave teh vdpa device attach | |
| 15:55:27 | sean-k-mooney | dmitriis: by the way at some point we likely need to consider how to supprot vdpa+bluefiled-2 | |
| 15:56:12 | sean-k-mooney | we can get the simple version working first however. | |
| 15:56:15 | dmitriis | sean-k-mooney: yes, I agree. There are two cases: software and hardware vDPA. For soft vDPA there is an extra agent needed on the hypervisor host. | |
| 15:56:22 | dmitriis | so that definitely has some challenges | |
| 15:56:50 | sean-k-mooney | im hoping we can simple not specify a device_type and relay on remote_manged=True | |
| 15:56:53 | dmitriis | another interesting area is Scalable Functions (SFs) which rely on mdev and a vendor-specific driver | |
| 15:57:02 | sean-k-mooney | well maybe not we can see | |
| 15:57:17 | sean-k-mooney | dmitriis: yes i have worked with that in the past | |
| 15:57:40 | dmitriis | it kind of erases the benefits of hardware virtio tbh | |
| 15:57:41 | sean-k-mooney | its not clear that the mdev based apparoch will go to market or not at least form teh vendor i was workign with | |
| 15:58:09 | sean-k-mooney | well the mdev impleation can be in hardware and present virtio too | |
| 15:58:20 | sean-k-mooney | it predates the vdpa buss | |
| 15:58:27 | dmitriis | ah, in that case, I take it back :^) | |
| 15:59:34 | whoami-rajat | Hi, just to be sure the nova meeting is in this channel right? | |
| 15:59:43 | dmitriis | I was also thinking of what CXL would bring and how much churn will it introduce to the existing PCI management implementation in Nova | |
| 15:59:49 | sean-k-mooney | the protype i was working on used an fpga to implent virtio in "hardware" but the long term plan was to do that in an asic. i just dont know if they have pivitored to vdpa now or not but it was mdev based at the time | |
| 16:00:10 | opendevmeet | The meeting name has been set to 'nova' | |
| 16:00:10 | opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | |
| 16:00:10 | opendevmeet | Meeting started Tue Nov 16 16:00:10 2021 UTC and is due to finish in 60 minutes. The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot. | |
| 16:00:10 | bauzas | #startmeeting nova | |
| 16:00:18 | gibi | o/ | |
| 16:00:21 | elodilles | o/ | |
| 16:00:28 | bauzas | #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting | |
| 16:00:48 | bauzas | good 'day, everyone ;) | |
| 16:00:52 | whoami-rajat | Hi | |
| 16:00:56 | opendevreview | Merged openstack/nova-specs master: Integration With Off-path Network Backends https://review.opendev.org/c/openstack/nova-specs/+/787458 | |
| 16:01:11 | gmann | o/ | |
| 16:01:38 | bauzas | I'll have to hardstop working in 45-ish mins, sooo | |
| 16:01:42 | opendevmeet | Current chairs: bauzas gibi | |
| 16:01:42 | bauzas | #chair gibi | |
| 16:01:44 | bauzas | sorry again | |
| 16:01:53 | gibi | so I will take the rest | |
| 16:02:13 | bauzas | anyway, let's start | |