13:03:32 <baoli> #startmeeting PCI Passthrough
13:03:33 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:03:35 <irenab> Did you have a chance to look at vnic_type patch?
13:03:36 <openstack> The meeting name has been set to 'pci_passthrough'
13:03:50 <baoli> Hi
13:03:59 <irenab> I need to rework it a bit, but want to see if in general it what you have in mind
13:04:14 <irenab> baoli: hi
13:05:03 <rkukura> irenab: I have not had a chance to review it closely yet, but will do that this morning.
13:05:23 <irenab> rkukra: thanks, wating for your inputs before rework
13:05:25 <sadasu> irenab: I am fine with whatever you have in your patch so far
13:05:43 <irenab> sadasu: thanks a lot for reviewing
13:05:48 <heyongli> what can we do more for nova side blue print?
13:06:21 <baoli> Irenab, I briefly looked at it, and it looks good. I will take a close look at it later.
13:06:35 <irenab> baoli: thanks.
13:06:44 <baoli> heyongli, welcome back
13:07:03 <irenab> somehow all 3rd party tests are broken, but I handle it once have rkukura comments
13:07:24 <rkukura> irenab: That's my top priority this AM
13:07:41 <heyongli> baoli, yeah, after one week
13:07:48 <irenab> baoli: Can represent the nova side?
13:07:50 <rkukura> irenab: I see your questions regarding the vif-details patch and can respond their and/or discuss here.
13:08:42 <baoli> 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 <irenab> Let's do it shortly now?
13:09:53 <rkukura> baoli: In general, MDs supply the binding:vif_detail value when they call PortContext.set_binding() from within MechanismDriver.bind_port()
13:11:12 <rkukura> 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 <rkukura> /alway/always/
13:11:50 <irenab> rkukura: why its done via _init__?
13:12:30 <rkukura> 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 <rkukura> 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 <irenab> why its based on vif_type and not vif_details being None?
13:13:55 <rkukura> Instead, the driver itself needs to call set_binding() from within check_segment_for_agent()
13:14:50 <rkukura> 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 <sadasu> rkukura: this is for non-agent based MDs ?
13:16:36 <irenab> 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 <rkukura> 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 <sadasu> rkukura: ok
13:17:19 <rkukura> irenab: The derived class can definitely use a static vif_type when it calls set_binding()
13:17:52 <irenab> sadasu: I think you are first who adds MD that capable to bind port and does not have agent
13:18:14 <sadasu> irenab: thats right!
13:18:17 <rkukura> 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 <rkukura> sadasu: I think the ODL MD that's in review also binds ports without an agent.
13:19:03 <sadasu> rkukura: ok
13:19:09 <irenab> 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 <sadasu> rkukura: will take a look at this MD...but I understand your explanation
13:20:09 <rkukura> 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 <rkukura> 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 <rkukura> Should have an updated patch later today, and maybe an initial patch for binding:profile.
13:21:38 <irenab> rkukura: Ok, I think I got it. So PortContext.set_binding() will override the vif_details in __init__?
13:21:59 <irenab> rkukura: great
13:22:04 <rkukura> irenab: If vif_details are static (don't depend on anything else) then thats fine.
13:22:31 <irenab> they may depend on network details, like vlan id
13:22:54 <rkukura> 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 <irenab> rkukra: Is there any flow chart for the ML2 port-create?
13:24:43 <irenab> if not, I'll definitely do one
13:24:58 <rkukura> 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 <irenab> rkukura: is this item already under development?
13:26:15 <sadasu> irenab: my thoughts exactly about the flow chart!
13:26:29 <rkukura> 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 <irenab> rkukura: so it is also on your table?
13:26:58 <rkukura> But since MDs are impacted, and feature freeze does apply to them, it needs to get done ASAP.
13:27:23 <rkukura> It flowed off my plate onto my table;-)
13:28:05 <irenab> rkukura: :-)
13:28:25 <irenab> to cover the nova part for vif_details changes
13:28:32 <baoli> 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 <rkukura> baoli: correct
13:29:16 <baoli> rkukura, so each port is associated with a single MD, right?
13:29:49 <irenab> baoli: bound by one MD, I think is more correct to say
13:30:19 <baoli> Ok, so a port can only be bound to a single MD.
13:30:33 <sadasu> 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 <rkukura> 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 <rkukura> 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 <baoli> that sounds interesting. In that case, the overwritting behavior would be an issue?
13:32:48 <rkukura> 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 <irenab> I suggest to solve the short term first ;-) Its already complicated enough
13:33:06 <rkukura> irenab: good point!
13:33:43 <baoli> agreed
13:34:04 <irenab> coming back to nova, I saw that baoli suggests to cover vif_details and profile as part of his changes
13:34:41 <irenab> I think that vif_details are also required for port security
13:34:48 <rkukura> 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 <baoli> I posted a patch https://review.openstack.org/#/c/67500/
13:35:42 <irenab> rkukura: Now I see Mark already unblocked it
13:36:45 <baoli> Irenab, are you talking about adding vif_details and profile into the VIF object as a separate BP?
13:37:03 <irenab> 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 <baoli> 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 <irenab> 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 <irenab> will send the link to review once pushed
13:38:53 <rkukura> baoli: I'll review that today too.
13:39:11 <baoli> rkukura, great
13:39:30 <irenab> baoli: I started to look, will poss comments later today
13:39:43 <baoli> irenab, thanks.
13:39:47 <irenab> ^post
13:40:22 <irenab> heyongli: any updates on your patches?
13:40:59 <heyongli> yunhong get some work done, i still work on that, will soon refresh it i think
13:41:41 <irenab> baoli: for vif_details, it changed the portbonding attribute, so I am  ot sure if it breaks the nova code
13:42:24 <baoli> 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 <rkukura> irenab: Do you mean the old binding:capabilities attribute?
13:42:36 <heyongli> baoli: sure
13:42:43 <irenab> rkukura: yes
13:43:16 <rkukura> irenab: It seems all reference to binding:capabilities had been removed from nova early in icehouse.
13:43:49 <irenab> rkukura: Ok, so then it should not affect the current code
13:44:43 <irenab> baoli: maybe yu just need to push support as small patches on same bp, to make nova cores comfortable with review
13:45:28 <baoli> Irenab, if it becomes big, I would think about doing that. So far, it's not that bad
13:46:11 <irenab> baoli: fair enough
13:46:22 <rkukura> 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 <irenab> so we need to decide on contnt/format for binding:profile and binding:vif_details for SRIOV ports
13:47:19 <baoli> 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 <irenab> baoli: agree
13:48:10 <rkukura> I'm not clear on why VIF.port_profile is needed. Will nova be setting this, looking at this, or both?
13:48:42 <sadasu> rkukura: nova will look at this
13:48:46 <baoli> rkukrua, information in VIF.port_profile will be needed by the vif driver
13:48:57 <irenab> rkukura: we need to propagate to neutron the SRIOV device details
13:49:12 <rkukura> Sounds like it both sets and looks at it
13:49:34 <sadasu> VIF.port_profile is purely from neutron to nova
13:50:04 <rkukura> 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 <baoli> rkukura, VIF.port_profile will be set while creating/updating a port. Later the port will be queried and VIF created
13:50:29 <irenab> and by L2 agent if exists
13:50:30 <sadasu> 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 <baoli> I should have said, port.binding.profile will be set while creating/updateing a port
13:51:17 <rkukura> sadasu: I think you need to use binding:vif_details to pass data from neutron to nova.
13:51:51 <baoli> rkukura, with port query from nova, port.binding.profile will be returned to nova
13:52:02 <rkukura> baoli: I'm fine with storing binding:profile in the VIF object if that's needed
13:52:10 <sadasu> rkukura: yes....its the vif_details....port_profile is in the nova->neutron direction correct?
13:52:18 <baoli> rkukrua, ok
13:52:23 <rkukura> sadasu: right
13:52:48 <rkukura> but of course nova or any client can read the binding:profile value too
13:52:54 <irenab> so if binding:profile exists it vill be set in binding:vif_details.profile ?
13:53:08 <baoli> rkukura, from neutron side, you can enforce that rule. But from nova side, both are available from the port object
13:53:33 <baoli> irenab, not really
13:53:53 <rkukura> baoli: Correct, but any attempt to modify binding:vif_type or binding:vif_details via the API will fail
13:54:22 <baoli> rkukura, that's right. But nova wouldn't try to do that
13:54:32 <irenab> I am trying to undestand rkukura suggestion for neutron->nova flow
13:54:49 <sadasu> rkukura: nova doesn't have to modify those fields
13:54:55 <irenab> with regards to binding:profile content that need to be passed to VIFDriver
13:55:12 <rkukura> I think we all are clear on the directions of flow at this point!
13:55:44 <rkukura> I've got another meeting in 5 minutes
13:55:55 <sadasu> yes...just the same names are re(used) in a diff context
13:56:19 <irenab> rkukura: so you are ok with baoli suggestion ?
13:56:50 <rkukura> The suggestion to store binding:vif_details and binding:profile dicts in VIF object?
13:56:54 <sadasu> actually I am ok with vif_details...can we talk about VIF.port_profile?
13:56:58 <rkukura> I'm fine with that
13:57:33 <sadasu> rather binding:profile...
13:57:38 <sadasu> what would be the contents?
13:57:40 <baoli> We need to decide the fields in binding:profile
13:57:49 <irenab> baoli: agree
13:57:59 <baoli> But let's wrap it up today. Let's do that first thing tomorrow morning
13:58:07 <rkukura> 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 <irenab> according to the google doc, we have vendor_id, product_id and slot addres
13:58:21 <sadasu> rkukura: correct
13:58:41 <sadasu> irenab: your MD needs it?
13:58:57 <irenab> rkukura: not sure why its on profile and not vif_details
13:59:19 <sadasu> vif_details is neutron->nova
13:59:26 <irenab> sadasu: the device ID, yes
13:59:33 <baoli> I need to attend to another meeting too. So can we resume tomorrow morning?
13:59:43 <baoli> We can also exchange emails.
13:59:44 <rkukura> I would think any SR-IOV MD would use this in bind_port() to pick the right network segment when binding
13:59:53 <irenab> baoli: sure, let's try via email too
14:00:03 <rkukura> OK, email, IRC, ...
14:00:07 <baoli> #endmeeting