Earlier  
Posted Nick Remark
#openstack-nova - 2023-10-09
15:46:32 dvo-plv sean-k-mooney, Hello
15:46:54 sean-k-mooney dvo-plv: o/
15:47:11 dvo-plv I would like to discuss out blueprint regarding NT NIC support. But it too late today, can we talk tomorrow?
15:47:34 dvo-plv when it will be comfortable for you ?
15:51:05 sean-k-mooney honestly i need to reload context.
15:51:36 sean-k-mooney so we can chat during the week but im not sure when ill be free. ping me durnign the week when your around
16:23:49 dansmith sean-k-mooney: I'm calling it a followup to the original BP, which is why I tagged it as such
16:40:20 sean-k-mooney ack
16:41:10 sean-k-mooney i didnt sleep great last night so i may not get to it today but if i dont ill review them tommorow if someone else does not review them in the interim
16:41:42 dansmith no rush
17:37:34 opendevreview Dan Smith proposed openstack/nova master: WIP: Compile mdev samples for nova-next https://review.opendev.org/c/openstack/nova/+/897708
17:42:12 opendevreview Dan Smith proposed openstack/nova master: WIP: Compile mdev samples for nova-next https://review.opendev.org/c/openstack/nova/+/897708
17:50:07 opendevreview sean mooney proposed openstack/nova master: add initial healthcheck support https://review.opendev.org/c/openstack/nova/+/825015
18:39:29 opendevreview Dan Smith proposed openstack/nova master: WIP: Compile mdev samples for nova-next https://review.opendev.org/c/openstack/nova/+/897708
18:45:51 opendevreview Merged openstack/nova master: cpu: make governors to be optional https://review.opendev.org/c/openstack/nova/+/885352
18:46:07 opendevreview sean mooney proposed openstack/nova master: add initial healthcheck support https://review.opendev.org/c/openstack/nova/+/825015
20:16:23 opendevreview Dan Smith proposed openstack/nova master: WIP: Compile mdev samples for nova-next https://review.opendev.org/c/openstack/nova/+/897708
21:16:52 opendevreview Dan Smith proposed openstack/nova master: WIP: Compile mdev samples for nova-next https://review.opendev.org/c/openstack/nova/+/897708
21:58:11 opendevreview Dan Smith proposed openstack/nova master: WIP: Compile mdev samples for nova-next https://review.opendev.org/c/openstack/nova/+/897708
#openstack-nova - 2023-10-10
01:06:09 opendevreview melanie witt proposed openstack/nova master: Add encryption support to convert_image https://review.opendev.org/c/openstack/nova/+/870934
05:52:00 opendevreview Amit Uniyal proposed openstack/nova master: Adds device tagging functional tests https://review.opendev.org/c/openstack/nova/+/895162
06:00:36 opendevreview Amit Uniyal proposed openstack/nova master: Adds device tagging functional tests https://review.opendev.org/c/openstack/nova/+/895162
06:35:33 opendevreview Amit Uniyal proposed openstack/nova master: Adds device tagging functional tests https://review.opendev.org/c/openstack/nova/+/895162
07:13:47 hamidlotfi_ Hi there,
07:13:47 hamidlotfi_ In the nova database, I see much `LOCK WAIT` on the `neutron.ports` table
07:13:47 hamidlotfi_ and I putting a sample log for the lock wait
07:13:47 hamidlotfi_ I want to know if is this a bug in the structure of a table or the script of the update or the user mistake.
07:13:52 hamidlotfi_ https://www.irccloud.com/pastebin/o4HQQaEK/
09:54:27 hamidlotfi_ @dansmith @bauzas @sahid_
10:22:41 dvo-plv sean-k-mooney, Are you here ?
10:44:28 sean-k-mooney dvo-plv: o/
10:45:13 dvo-plv I wouldl iek to talk with you regarding out blueprint nt nic support, if you have free time for it
10:45:46 dvo-plv previously we decided that we will try to pass socket name with ovs command for dpdk port type
10:47:09 sean-k-mooney yes and i ask can we pass the name to ovs when addign the port so that we didn not have to compute one that matched the nic driver format
10:47:45 sean-k-mooney we also discussed that some of the magic constant are actully discoverable form sysfs like the vf offset
10:48:13 dvo-plv yes
10:49:19 dvo-plv we spent some time on the investigation and this is not possible to do it for dpdk port type with ovs. there will be alot of changes, DPDK community will not approve it
10:49:57 sean-k-mooney thats not ideal
10:50:23 dvo-plv So I would like to get back to the separate os-vif plugin
10:50:45 dvo-plv what do you think about that ?
10:50:50 sean-k-mooney not nessiarly what that means is that nova needs to tell neutron the vf specific info
10:51:20 sean-k-mooney so we need to pass info to the ml2 driver in the binding_profile
10:51:52 sean-k-mooney neutron can then use that to generate the socket path. alternitivly we could jsut generate the path ourselve in nova
10:52:21 dvo-plv path is not a problem, specific socket name is the root cause
10:52:44 sean-k-mooney the socket name is path of the path :)
10:52:47 sean-k-mooney but yes
10:54:51 dvo-plv So, we can somehow use port binding profile for this purposes?
10:56:17 sean-k-mooney yes that is what its for to pass info form nova to the network backend
10:56:27 sean-k-mooney we normally sotre the pci_adress in it
10:56:44 sean-k-mooney but we can have other fields like the offset ectra
10:56:59 sean-k-mooney or we can just comppute the socket name and pass that
10:57:07 sean-k-mooney which is proably the better option
10:57:30 sean-k-mooney since nova does not have the base path (neutron/ovs does have that info)
10:57:53 sean-k-mooney so we can provide the socket name in the binding profile and neutron can append that to the base socket path
10:58:03 sean-k-mooney and then we will get the full path back which we can store in the xml
11:00:20 dvo-plv okay, i see. but i have a question how we should handle pci. for socket name stdvio10, we need to use pci 0000:65:01.2. So we need vendor specific mechanism for parse socket name
11:00:41 sean-k-mooney its the other way around
11:00:49 sean-k-mooney we are selecting VFs in the pci tracker
11:01:01 sean-k-mooney and you need to compute the socket name from the adress
11:01:45 sean-k-mooney the main issue i think is still the multi device support
11:02:07 sean-k-mooney since the previous algorthim did not support more hten one nic
11:03:17 dvo-plv yes, currently we do not support multinic setup
11:03:44 sean-k-mooney right so i dont think we should support this in nova until that is addressed
11:04:57 dvo-plv Honestly, i forget about that, I will investigate internal if we have some plan how this should be done in the future, because as far as I know we have plan to provide this feature
11:06:02 dvo-plv But if this is a limitation for be in the common code, what about to pass us with separate os-vif plugin, which will handle all this issuses ?
11:06:57 sean-k-mooney a out of tree os-vif plugin will also reqiure your own ml2 driver in neutron
11:08:17 dvo-plv yes, we can implement it too, like Agilio https://github.com/Netronome/agilio-ovs-openstack-plugin/tree/master/vif_plug_agilio_ovs
13:57:13 opendevreview Dan Smith proposed openstack/nova master: WIP: Compile mdev samples for nova-next https://review.opendev.org/c/openstack/nova/+/897708
13:58:11 dansmith bauzas: this is getting close to working ^
13:58:29 bauzas dansmith: wow, thanks
14:00:36 dansmith last round only failed because I didn't sudo something
14:01:48 sean-k-mooney dansmith: would you mind in a followup allowing us to enabel other moduels
14:02:11 sean-k-mooney i.e. mdpy or mbochs?
14:02:13 dansmith sean-k-mooney: yeah I was going to do all the samples, I just wanted to get the mechanics working
14:02:32 dansmith or do you mean *any* other module?
14:03:05 sean-k-mooney i was thinking of makign CONFIG_SAMPLE_VFIO_MDEV_MTTY=m
14:03:11 sean-k-mooney a list
14:03:20 sean-k-mooney but mainly jsut the mtty samples
14:04:08 sean-k-mooney it might be nice if the set of flags to enable in the kernel config was just a var you could set in the local.conf
14:04:24 sean-k-mooney although
14:04:28 sean-k-mooney looking at it again
14:04:30 dansmith it's not that easy
14:04:36 sean-k-mooney you alls need to call make per module
14:04:44 sean-k-mooney so ya never mind
14:04:55 dansmith unless you want to build the whole kernel, you need to know configs and target module files, and the deps
14:05:01 bauzas fwiw, this will actually depend on what we can do with live-migration :)
14:05:10 dansmith but yeah, I'll extend this to do all the mdev samples
14:05:13 sean-k-mooney dansmith: ya lets keep it simple
14:05:13 bauzas if that's done per mtty, cool
14:05:18 dansmith bauzas: oh I know, but we could also apply a patch here
14:05:35 bauzas yeah, let's just start this simple with mtty
14:05:47 sean-k-mooney bauzas: so this is useful even without live migration
14:05:57 bauzas yup, definitely
14:06:09 sean-k-mooney it woudl be a majory win just to get any coverage of mdevs
14:06:59 sean-k-mooney so ya we can add follow up patches to do the nova config generation to enabel them
14:07:10 sean-k-mooney but that would be good to do in the devstack plugin to
14:07:47 dansmith yeah, point me at what I need to do config-wise
14:07:58 sean-k-mooney you technnially dont need that since we can just shove config snipit into config via local.conf
14:08:28 dansmith ack, but if it can do something for each sample it finds or something...
14:08:39 sean-k-mooney am [device]enabled_mdev_types ...

Earlier   Later