13:00:21 <baoli> #startmeeting PCI Passthrough
13:00:21 <openstack> Meeting started Wed Feb 12 13:00:21 2014 UTC and is due to finish in 60 minutes.  The chair is baoli. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:00:22 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:00:24 <openstack> The meeting name has been set to 'pci_passthrough'
13:00:36 <rkukura> hi everyone!
13:00:44 <baoli> Hi rkukura
13:00:52 <irenab> hi
13:01:26 <baoli> wait for a couple of more minutes and see if more will join
13:01:54 <beagles> hi
13:02:01 <sadasu> hello
13:06:58 <irenab> Can we start?
13:07:17 <baoli> I was hoping that Yongli He would join. But let's get started
13:07:32 <baoli> Let's discuss binding:profile
13:07:52 <baoli> Irenab, saw your email.
13:08:13 <irenab> baoli: what is your opinion?
13:08:19 <baoli> So you'd like to have "vendor_id:product_id", and "domain:bus:slot.fu"
13:08:24 <sadasu> Irena: missed replying yesterday
13:08:35 <sadasu> I sent reply now
13:09:26 <irenab> baoli: I think SRIOV MD will need to filter if to handle the port binding based on vendor:product
13:09:57 <sadasu> I am OK with separation for  'vendor_id:product_id', 'domain:bus:slot.func'
13:10:11 <baoli> irenab, I'm fine with it.
13:10:12 <sadasu> irenab: correct about filtering
13:10:33 <sadasu> are they going to be 2 seperate strings?
13:10:40 <baoli> So we name the field something like: pci_vidpid, pci_slot.
13:10:53 <rkukura> I've read the emails too. I'll forward them to beagles, who is here from Red Hat and is much more familiar with the nova code than I am.
13:10:56 <baoli> sadasu, yes, it's going to be strings
13:11:16 <baoli> HI beagles
13:11:21 <irenab> baoli: this makes sense to me
13:11:26 <beagles> hi, baoli (and thanks rkukura)
13:11:28 <sadasu> Hi rkukura!
13:11:37 <irenab> beagles: wellcome to the club :-)
13:11:49 <sadasu> welcome beagles
13:12:02 <beagles> thanks!
13:12:35 <baoli> So binding:profile:pci_vidpid = "vendor_id:product_id", binding:profile:pci_slot = "domain:bus:slot.func"
13:12:47 <sadasu> +1
13:13:12 <irenab> baoli: generally agree
13:13:29 <irenab> maybe need more friendly name for vidpid
13:13:42 <baoli> irenab, what do you suggest?
13:13:50 <rkukura> I'm OK with these formats, but am not familiar enough with the nova scheduling and PCI code to know if there are any implications
13:14:54 <irenab> baoli: no good ideas, maybe something like pci_vendor_spec
13:14:55 <baoli> rkukura, this is input from nova to neutron while creating/updating a port. We'll get to the physical net name in a bit
13:15:21 <rkukura> baoli: Understood
13:15:32 <irenab> let's start with your suggestion and see if better name comes up
13:15:46 <sadasu> pci_vender_info ?
13:15:52 <sadasu> just throwing it out there
13:16:02 <irenab> sadasu: sounds good
13:16:02 <baoli> irenab, vidpid is vendor_id_product_id but vendor_spec is kind of big.
13:16:54 <baoli> ok, pci_vendor_info is better
13:17:02 <sadasu> pci_vidpid, pci_vendor_spec, pci_vendor_info, 3 choices so far...lets move this discussion to the thread
13:17:22 <irenab> I am fine with pci_vendor_info
13:17:36 <baoli> ok, let's call it pci_vendor_info
13:17:42 <sadasu> ok....phy_net discussion now?
13:17:53 <baoli> Let's move on to the phy net name
13:18:32 <sadasu> rkukura: we need phy-net to be part of binding_profile bcuz of multiprovidernet extension?
13:18:35 <baoli> Hi Heyongli
13:18:51 <heyongli> sorry, later, baoli,
13:18:56 <baoli> We are just discussing the fields in binding:profile
13:18:56 <irenab> rkukura: Is it also required for non SRIOV case?
13:19:09 <rkukura> sadasu: The ML2 model for networks is that they can have multiple segments
13:19:34 <rkukura> The multiprovidernet API extension lets admins create these, and see the details.
13:20:17 <sadasu> rkukura: ok
13:20:49 <rkukura> Even if we don't end up having the nova code in icehouse use multiprovidernet, I believe we should define the interaction between nova and neutron so that nova tells neutron which phyiscal_network its SR-IOV device is connected to
13:21:19 <sadasu> rkukura: I agree
13:21:46 <rkukura> The code in the mechanism driver will just need one additional line to compare this to the segment's physical_network as it iterates through the segments (see the AgentMechanismDriverBase)
13:21:53 <sadasu> I am fuzzy about how the diff segments would be considered for scheduling decision in nova
13:21:59 <irenab> rkukura: I am not sure why nova will send physical network name to neutron on create port, we currently plan to get physicla network name from neutron
13:22:44 <sadasu> rkukura: agree
13:22:50 <rkukura> irenab: If nuetron networks never had multiple segments, this info would be redundant, but multiple segments are possible
13:23:20 <rkukura> sadasu: I also am fuzzy about how nova's scheduling would handle multiple segment networks
13:24:12 <rkukura> The filter would need to allow compute nodes that have an SR-IOV device connected to any of the physical_networks.
13:25:05 <irenab> rkukura: so nova code that baoli plan, should support multisegment networks for scheduling decision?
13:25:31 <rkukura> But if the instance has multiple SR-IOV ports, then the filter needs to only allow compute nodes with the correct number of available devices, each connected to one of the physical_networks for a specific port's network
13:26:00 <rkukura> If baoli knows how to make the scheduling work, that would be great.
13:26:16 <sadasu> :-)
13:26:32 <irenab> rkukura: by filter you mean the MD validate_port_binding sequence?
13:26:35 <baoli> rkukura, as exchanged in the email, each compute node would tag their devices with the phsical network it supports
13:27:18 <baoli> Then it becomes a matter of finding a compute node that satisfy: net-group = phy-net1 OR net-group = phy-net2 OR ....
13:27:19 <rkukura> But even if we start initially with the nova code only using the old providernet extension, I think the binding:profile:physical_network should be sent to neutron and neutron should ensure that the port binds to a segment with that physical_network
13:27:50 <irenab> rkukura: agree
13:28:01 <rkukura> baoli: That works fine for a single port.
13:28:17 <baoli> rkukura, what do you mean by single port?
13:28:19 <rkukura> It gets fuzzy for me when their are multiple ports, each with its own list of physical_networks
13:28:39 <baoli> rkukura, it works the same way
13:28:41 <rkukura> baoli: The instance only connects to one SR-IOV network.
13:29:22 <baoli> rkukura, can you be more specific by "connect to one SR-IOV network"
13:29:29 <rkukura> I guess I wasn't sure that we'd be writing logic for the scheduling filter, or trying to setup tags so that some existing filter logic would do what we need
13:29:51 <rkukura> If the former, I don't think handling multiple SR-IOV ports per instance should be difficult.
13:30:04 <irenab> rkukura: for virtio ports, the multi segment network case will be worked by neutron only?
13:30:11 <baoli> rkukura, we can come up with a new filter.
13:30:16 <rkukura> irenab: correct
13:30:54 <baoli> rkukura, can you describe the non-sriov case?
13:31:31 <irenab> rkukura: so SRIOV  MD will need to update some segment related DB table?
13:32:07 <rkukura> baoli: By "connect to one SR-IOV network", I mean that the user has done something like "nova boot --nic [1st SR-IOV port info] --nic [2nd SR-IOV port info] ...
13:32:40 <irenab> rkukura, baoli:  I think this case should work
13:33:11 <irenab> it should work also for mixing sriov and non-sriov ports for same VM
13:33:16 <rkukura> In the non-SR-IOV case with the agent-based MDs, the ML2 plugin's port binding code iterates over the registered MDs to try to bind, calling bind_port() on each
13:33:58 <rkukura> Within the AgentMechanismDriverBase.bind_port() implementation, it iterates over the network segments, calling check_segment_for_agent() on the derived class for each segment.
13:35:02 <rkukura> The 1st segment that is tried for which the agent on the node identified by binding:host_id has a mapping for the segment's physical_network is used
13:35:09 <heyongli> baoli, i try to catch up the multi segment network what it will impact the device extra info?
13:35:32 <rkukura> The agents_db has these mappings via RPCs from the agents
13:35:41 <baoli> rkukura, so you'd check the vnic_type to decide to use the phy net name or iterate throught the MDs
13:36:25 <irenab> baoli: you still need to iterate through the MDs
13:36:37 <baoli> s/to use the phy net name/ to use the phy net name in binding:profile/
13:37:00 <rkukura> We'll need to add a line of code in the existing agent-based MDs check_segment_for_agent() to make sure vnic_type == 'virtio', so it won't bind when SR-IOV is required
13:37:27 <baoli> heyongli, I don't think so
13:37:44 <irenab> rkukura: it should be covered by vnic_type support in patch I pushed
13:37:56 <irenab> I'll check this case
13:38:04 <heyongli> baoli, seems all  network side's work
13:38:11 <rkukura> I think the SR-IOV MDs will need to iterate over the segments looking for the 1st one that has network_type of 'flat' or 'vlan' and that has the physical_network specified in binding:profile:physical_network
13:38:41 <baoli> heyongli, it may require enhancement to the pci filter in the scheduler
13:39:13 <rkukura> Then, for VLAN, the SR-IOV MDs can include the segment's segmentation_id within the binding:vif_details so that VIF driver can put that into the libvirt XML
13:39:34 <heyongli> baoli, does the requirement of the filter clear now?
13:39:52 <irenab> rkukura: makes sense
13:40:14 <irenab> sadsu: I think its the place you put the profileid for the port
13:40:17 <sadasu> rkukura: I think I am ok with what you said so far, will try to code it up today and ping if I have questions
13:40:42 <rkukura> sadasu: ok
13:40:45 <baoli> Heyongli, we still need to nail it down.
13:40:55 <baoli> ok, so we decide to add this in binding:profile
13:41:11 <baoli> now, comes to the name of the field
13:41:18 <sadasu> irenab: yes, i package segmentation id into my profileid and put that into vif_details
13:41:34 <irenab> so we have 3 strings on binding:profile
13:42:02 <baoli> we have pci_vendor_info, pci_slot
13:42:11 <irenab> binding:profile:physical_network, binding:profile:pci_vendor_info, binding:profile:pci_slot
13:42:25 <rkukura> irenab: +1
13:42:26 <sadasu> +1 from me
13:42:36 <baoli> agreed
13:43:05 <baoli> ok, move on to binding:vif_details
13:43:48 <baoli> we would have either binding:vif_details:profileid or binding:vif_details:vlan_id for the time being?
13:44:03 <sadasu> I think we need to have both?
13:44:19 <irenab> sadasu: +1
13:44:22 <sadasu> because the these will fill diff fields in the libvirt xml file
13:44:53 <irenab> it will be actually for different VIF Types
13:45:11 <baoli> sadasu, by "or", I mean that which field(s) is available depends on the vif types as Irenab indicated
13:45:48 <irenab> another question on VIF types, do we have 2 or 4 vif types?
13:46:17 <sadasu> baoli, irenab: agree for the dependency on vif type
13:46:33 <baoli> we have 802_1qbh and hw_veb to be implemented initially
13:46:43 <sadasu> direct, macvtap, virtio, hw_veb?
13:46:47 <irenab> I mean do we have vnic_type impact on VIF_TYPE or use it as additional field to decide how to create libvirt net interface XML
13:47:37 <irenab> 802_1qbh_direct, 802_1qbh_macvtap,...?
13:48:04 <baoli> irenab, vnic_type is available in the port object. I think that we'd use both vnic_type and vif_type to make that decision
13:49:17 <irenab> baoli: you will need to propogate the vnic_type to VIFDriver
13:49:35 <baoli> Irenab, yes
13:50:16 <irenab> baoli: OK
13:50:46 <baoli> I also want to add that the network xml will be a separate BP
13:51:08 <sadasu> for icehouse or juno?
13:51:33 <irenab> baoli: Fine with me.
13:51:38 <sadasu> going back, vnic_type would be part of vif_details?
13:51:52 <baoli> sadasu, Hopefully for icehouse, but we are too late
13:52:01 <irenab> sadasu: +1
13:52:04 <baoli> sadasu, vnic_type is part of the port object
13:52:18 <baoli> we have 10 minutes left. I want to discuss a little bit on our IRC meeting time
13:52:28 <irenab> baoli: I think it make sense to add it to VIF Details
13:52:49 <sadasu> how will nova access it ?
13:53:06 <sadasu> yes, in port object, but has to be part of vif_details too
13:53:09 <irenab> baoli: go ahead
13:53:21 <rkukura> If vnic_type is a top-level port attribute, can the nova code just put it into the VIF object for the driver to use?
13:53:42 <baoli> rkukura, that's what I thought
13:53:55 <baoli> ok, do we still need daily meeting?
13:54:16 <irenab> rkukura: nova will need to manage cases that vnic_type is not present in port (backward compatibility)
13:54:38 <baoli> and heyongli, I'd like to continue the nova side of things from tomorrow.
13:54:44 <heyongli> sure
13:54:57 <baoli> heyongli, cool, thanks
13:55:16 <heyongli> but i can not attend this on Friday
13:55:28 <baoli> irenab, the default value, if not present, is virtio, right?
13:55:44 <baoli> heyongli, we dont' have meeting on Friday
13:55:55 <heyongli> oh,,,
13:55:58 <irenab> baoli: It maybe old neutron
13:56:27 <baoli> irenab, are you suggesting that a NEW nova works with an OLD neutron?
13:56:28 <rkukura> baoli, irenab: I think it would be fine the nova VIF driver to default to virtio when the vnic_type is not present
13:56:55 <rkukura> Someone may need to think about what all this means for baremetal though;-)
13:57:46 <baoli> Heyongli, would Yunghong join tomorrow?
13:57:47 <irenab> rkukura: any chance you can take a look on the vnic_type patch?
13:58:26 <heyongli> baoli , i don't thinks so
13:58:37 <irenab> baoli: there can be plugins that not support vnic_type
13:58:46 <rkukura> irenab: yes
13:58:51 <baoli> Heyongli, shall we schedule a different time for nova side of things?
13:58:57 <irenab> agree with rkukura on setting default on nova side if vnic_type not present
13:58:57 <heyongli> he is on trip
13:59:05 <heyongli> baoli, also fine for me
13:59:20 <heyongli> for nova , bp is the big problem
13:59:22 <rkukura> irenab: I started looking, saw Eugene's comment about DB migrations, then went off an solved that for my vif-details patch!
13:59:44 <irenab> baoli: I would like to be in the loop for nova side as well
13:59:59 <baoli> irenab, I understand
14:00:07 <irenab> rkukura: I'll look how you solved it!
14:00:10 <beagles> baoli, I would also like to be in the loop on the nova side
14:00:25 * annegentle waves
14:00:30 <irenab> so  see,s we currenlty continue with daily meetings?
14:00:31 <baoli> So let's continue tomorrow same time, start with nova stuff.
14:00:49 <baoli> #endmeeting