13:03:32 #startmeeting PCI Passthrough 13:03:33 Meeting started Tue Feb 11 13:03:32 2014 UTC and is due to finish in 60 minutes. The chair is baoli. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:03:34 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:03:35 Did you have a chance to look at vnic_type patch? 13:03:36 The meeting name has been set to 'pci_passthrough' 13:03:50 Hi 13:03:59 I need to rework it a bit, but want to see if in general it what you have in mind 13:04:14 baoli: hi 13:05:03 irenab: I have not had a chance to review it closely yet, but will do that this morning. 13:05:23 rkukra: thanks, wating for your inputs before rework 13:05:25 irenab: I am fine with whatever you have in your patch so far 13:05:43 sadasu: thanks a lot for reviewing 13:05:48 what can we do more for nova side blue print? 13:06:21 Irenab, I briefly looked at it, and it looks good. I will take a close look at it later. 13:06:35 baoli: thanks. 13:06:44 heyongli, welcome back 13:07:03 somehow all 3rd party tests are broken, but I handle it once have rkukura comments 13:07:24 irenab: That's my top priority this AM 13:07:41 baoli, yeah, after one week 13:07:48 baoli: Can represent the nova side? 13:07:50 irenab: I see your questions regarding the vif-details patch and can respond their and/or discuss here. 13:08:42 rkukura, I looked at your patch briefly. One question I had is how the MD add their field, say the profileid or vlan field 13:08:52 Let's do it shortly now? 13:09:53 baoli: In general, MDs supply the binding:vif_detail value when they call PortContext.set_binding() from within MechanismDriver.bind_port() 13:11:12 So previously, for agent-based MDs using AgentMechanismDriverBase, the base class would alway make this call, passing binding:vif_type setup during __init__(). 13:11:28 /alway/always/ 13:11:50 rkukura: why its done via _init__? 13:12:30 Now, the driver can supply both binding:vif_type and binding:vif_details in the __init__() call, or pass None for these 13:13:07 If they pass pass None for bindig:vif_type, then the base class no longer calls PortContext.set_binding() when the driver's bind_port() returns True. 13:13:53 why its based on vif_type and not vif_details being None? 13:13:55 Instead, the driver itself needs to call set_binding() from within check_segment_for_agent() 13:14:50 This approach makes it easy for drivers whose vif_type and vif_details will always be the same, but lets them set them dynamically if needed 13:15:29 rkukura: this is for non-agent based MDs ? 13:16:36 I just think it should be possible to Agent based MDs to set VIF Details even when vif_type is always the same. vif_details may still be changed 13:16:40 sadasu: All the way AgentMechanismDriverBase deals with getting vif_type and vif_details from the derived class only applies for agent-based MDs 13:17:12 rkukura: ok 13:17:19 irenab: The derived class can definitely use a static vif_type when it calls set_binding() 13:17:52 sadasu: I think you are first who adds MD that capable to bind port and does not have agent 13:18:14 irenab: thats right! 13:18:17 sadasu: All MDs that can bind ports need to call PortContext.set_binding() from within their bind_port() method. The agent base class just provides some structure for this. 13:19:02 sadasu: I think the ODL MD that's in review also binds ports without an agent. 13:19:03 rkukura: ok 13:19:09 rkukura: OK, so for Agent based MD that need to modify vif_details, it is required to override the base bind_port method? 13:19:39 rkukura: will take a look at this MD...but I understand your explanation 13:20:09 irenab: They can ovveride bind_port(), but that kind of defeats the purpose of the base class. Instead, they can call PortContext.set_binding() themselves from within check_segment_for_agent(). 13:21:09 I'll try to clarify things a bit in the review. I also need to do the DB migration so the tempest tests will run. 13:21:37 Should have an updated patch later today, and maybe an initial patch for binding:profile. 13:21:38 rkukura: Ok, I think I got it. So PortContext.set_binding() will override the vif_details in __init__? 13:21:59 rkukura: great 13:22:04 irenab: If vif_details are static (don't depend on anything else) then thats fine. 13:22:31 they may depend on network details, like vlan id 13:22:54 irenab: But if you need to put the VLAN tag in vif_details, you'll need to call PortContext.set_binding() from within check_segment_for_agent() instead. 13:23:55 rkukra: Is there any flow chart for the ML2 port-create? 13:24:43 if not, I'll definitely do one 13:24:58 irenab: Not that I'm aware of. Note that the internal handling of this by the plugin will be changing significantly. See http://lists.openstack.org/pipermail/openstack-dev/2014-February/026344.html 13:25:34 rkukura: is this item already under development? 13:26:15 irenab: my thoughts exactly about the flow chart! 13:26:29 Coding hasn't started yet. That's next after binding:profile. This is to address two bugs, not a new BP, so feature freeze doesn't apply. 13:26:53 rkukura: so it is also on your table? 13:26:58 But since MDs are impacted, and feature freeze does apply to them, it needs to get done ASAP. 13:27:23 It flowed off my plate onto my table;-) 13:28:05 rkukura: :-) 13:28:25 to cover the nova part for vif_details changes 13:28:32 rkukura, I need more time to look at your patch. But another question, any time set_binding is called, the values will be overwritten (not updated), is that right? 13:28:44 baoli: correct 13:29:16 rkukura, so each port is associated with a single MD, right? 13:29:49 baoli: bound by one MD, I think is more correct to say 13:30:19 Ok, so a port can only be bound to a single MD. 13:30:33 rkukura: set_binding() is always invoked only by the MD or is there some ML2 internal logic that can trigger set_binding() at other times? 13:30:36 baoli: Right now, a single MD is involved in the binding, but all MDs have their create/update/delete precommit and postcommit() calls made, so they can observe things 13:31:12 long term, we may want to do some sort of composite bindings that involve MDs at the vswitch, ToR switch, core switch layers, or something 13:31:52 that sounds interesting. In that case, the overwritting behavior would be an issue? 13:32:48 baoli: Maybe, but since vif_details is really specifically intended for the VIF driver, it probably only should come from the lowest level part of the composite binding 13:32:57 I suggest to solve the short term first ;-) Its already complicated enough 13:33:06 irenab: good point! 13:33:43 agreed 13:34:04 coming back to nova, I saw that baoli suggests to cover vif_details and profile as part of his changes 13:34:41 I think that vif_details are also required for port security 13:34:48 irenab: I was chatting with markmclain prior to the neutron team IRC meeting, and asked about the "blocked" status on your BP. I think this was due to it potentially needing the binding:profile BP implemented first. That's not the case, so I think it can be unblocked. 13:35:39 I posted a patch https://review.openstack.org/#/c/67500/ 13:35:42 rkukura: Now I see Mark already unblocked it 13:36:45 Irenab, are you talking about adding vif_details and profile into the VIF object as a separate BP? 13:37:03 baoli: getting physicla_netowrk for netowrk is added as bug fix I raised yesteday, and we need it for current Mlnx support too, it will be pushed later today by Itzik 13:37:53 irenab, that's good, will take a look. But what's your concern with vif_details and profile on the nova side? 13:38:08 I think it will be small enough and easy for nova cores to review, so you can assume you will get the method to get provider_net info 13:38:26 will send the link to review once pushed 13:38:53 baoli: I'll review that today too. 13:39:11 rkukura, great 13:39:30 baoli: I started to look, will poss comments later today 13:39:43 irenab, thanks. 13:39:47 ^post 13:40:22 heyongli: any updates on your patches? 13:40:59 yunhong get some work done, i still work on that, will soon refresh it i think 13:41:41 baoli: for vif_details, it changed the portbonding attribute, so I am ot sure if it breaks the nova code 13:42:24 heyongli, I posted some comments the other day on your patches. Please also take a look at my patch and look for the APIs that it calls into the generic PCI modules. 13:42:25 irenab: Do you mean the old binding:capabilities attribute? 13:42:36 baoli: sure 13:42:43 rkukura: yes 13:43:16 irenab: It seems all reference to binding:capabilities had been removed from nova early in icehouse. 13:43:49 rkukura: Ok, so then it should not affect the current code 13:44:43 baoli: maybe yu just need to push support as small patches on same bp, to make nova cores comfortable with review 13:45:28 Irenab, if it becomes big, I would think about doing that. So far, it's not that bad 13:46:11 baoli: fair enough 13:46:22 irenab, baoli: I was hoping to push a small nova patch that simply included the binding:vif_details dictionary in the VIF object. The idea was for this to be used for the SR-IOV and for the VIF security work. 13:47:01 so we need to decide on contnt/format for binding:profile and binding:vif_details for SRIOV ports 13:47:19 So regarding vif_details and profile, we'd create two fields in VIF object, something like VIF.vif_details, VIF.port_profile? 13:47:46 baoli: agree 13:48:10 I'm not clear on why VIF.port_profile is needed. Will nova be setting this, looking at this, or both? 13:48:42 rkukura: nova will look at this 13:48:46 rkukrua, information in VIF.port_profile will be needed by the vif driver 13:48:57 rkukura: we need to propagate to neutron the SRIOV device details 13:49:12 Sounds like it both sets and looks at it 13:49:34 VIF.port_profile is purely from neutron to nova 13:50:04 So are we saying that if it already exists, it will get stuffed into VIF.port_profile, then modified and updated on the port, then used by the VIF driver? 13:50:27 rkukura, VIF.port_profile will be set while creating/updating a port. Later the port will be queried and VIF created 13:50:29 and by L2 agent if exists 13:50:30 my MD creates a port_profile, has to pass it to nova via VIF.port_profile and will be used by the genericVifDriver 13:50:54 I should have said, port.binding.profile will be set while creating/updateing a port 13:51:17 sadasu: I think you need to use binding:vif_details to pass data from neutron to nova. 13:51:51 rkukura, with port query from nova, port.binding.profile will be returned to nova 13:52:02 baoli: I'm fine with storing binding:profile in the VIF object if that's needed 13:52:10 rkukura: yes....its the vif_details....port_profile is in the nova->neutron direction correct? 13:52:18 rkukrua, ok 13:52:23 sadasu: right 13:52:48 but of course nova or any client can read the binding:profile value too 13:52:54 so if binding:profile exists it vill be set in binding:vif_details.profile ? 13:53:08 rkukura, from neutron side, you can enforce that rule. But from nova side, both are available from the port object 13:53:33 irenab, not really 13:53:53 baoli: Correct, but any attempt to modify binding:vif_type or binding:vif_details via the API will fail 13:54:22 rkukura, that's right. But nova wouldn't try to do that 13:54:32 I am trying to undestand rkukura suggestion for neutron->nova flow 13:54:49 rkukura: nova doesn't have to modify those fields 13:54:55 with regards to binding:profile content that need to be passed to VIFDriver 13:55:12 I think we all are clear on the directions of flow at this point! 13:55:44 I've got another meeting in 5 minutes 13:55:55 yes...just the same names are re(used) in a diff context 13:56:19 rkukura: so you are ok with baoli suggestion ? 13:56:50 The suggestion to store binding:vif_details and binding:profile dicts in VIF object? 13:56:54 actually I am ok with vif_details...can we talk about VIF.port_profile? 13:56:58 I'm fine with that 13:57:33 rather binding:profile... 13:57:38 what would be the contents? 13:57:40 We need to decide the fields in binding:profile 13:57:49 baoli: agree 13:57:59 But let's wrap it up today. Let's do that first thing tomorrow morning 13:58:07 One field in binding:profile we've discussed is the chosen physical_network to which the SR-IOV device is attached, right? 13:58:17 according to the google doc, we have vendor_id, product_id and slot addres 13:58:21 rkukura: correct 13:58:41 irenab: your MD needs it? 13:58:57 rkukura: not sure why its on profile and not vif_details 13:59:19 vif_details is neutron->nova 13:59:26 sadasu: the device ID, yes 13:59:33 I need to attend to another meeting too. So can we resume tomorrow morning? 13:59:43 We can also exchange emails. 13:59:44 I would think any SR-IOV MD would use this in bind_port() to pick the right network segment when binding 13:59:53 baoli: sure, let's try via email too 14:00:03 OK, email, IRC, ... 14:00:07 #endmeeting