13:00:12 <baoli> #startmeeting PCI Passthrough
13:00:13 <openstack> Meeting started Wed Jan 29 13:00:12 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:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:00:16 <openstack> The meeting name has been set to 'pci_passthrough'
13:00:24 <baoli> Hi
13:00:32 <irenab> hi
13:00:54 <irenab> got notice from rkukura that he may late to the meeting
13:01:11 <baoli> Let's chat then before he joins
13:01:16 <irenab> sure
13:01:48 <irenab> I saw he pushed ML2 patch, will take a look soon
13:02:15 <baoli> He said that he will send out an email about his work, did you see that yet?
13:02:49 <irenab> I saw the patch #link https://review.openstack.org/#/c/69783/
13:03:09 <irenab> still didn't had chance to review. All day with sick kid...
13:03:48 <baoli> sorry to hear about that.
13:04:02 <irenab> thanks
13:04:10 <baoli> I will take a look at the patch later
13:04:24 <irenab> Are you ok with all nova pieces that need to be done?
13:04:52 <baoli> Well, I put some comments in their wiki. To be honest, I'm not exactly sure
13:05:24 <baoli> https://wiki.openstack.org/wiki/PCI_passthrough_SRIOV_support
13:05:42 <irenab> I may miss something, but there is no nova related config on Controller node?
13:05:58 <baoli> pci-flavor-attrs need to be there
13:06:13 <irenab> for short term, right?
13:06:16 <sadasu> hi sorry I am late, are we discussing baoli's wiki?
13:06:26 <baoli> even for longer term, I believe
13:06:46 <baoli> sadasu, we're waiting for rkukura to join
13:06:50 <sadasu> ok
13:06:55 <baoli> before that, we just chat
13:07:27 <irenab> how can I find your comments?
13:07:40 <baoli> irena, search for Robert
13:08:35 <irenab> baili: thanks, I see heyongli answered mostly all
13:11:16 <baoli> Hmm, some of my comments were missing
13:12:09 <irenab> baoli: once see with rkukura what is the mechanism to propogate in and out neutron port attributes, I plan to make Mech Driver. If you need help on nova pieces, let me know
13:13:56 <irenab> for the neutron port attributes, we need to decide on format for PCI slot details that nova will set
13:15:17 <baoli> irenab, yea, we need to finalize that for sure. we should start email thread on those
13:16:00 <baoli> irenab, I have a question for you regarding hw veb. Do you guys need this:<parameters managerid="11" typeid="1193047" typeidversion="2" instanceid="09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f"/>
13:16:36 <baoli> libvirt has them specifically for 802 1QBG
13:17:03 <irenab> baoli: not we do not need it, only what I added in initial Google doc.
13:17:23 <baoli> so the vlan id should suffice?
13:17:32 <irenab> baoli: yes
13:17:38 <baoli> cool
13:17:48 <irenab> baoli: great
13:18:14 <baoli> Hi rkukura
13:18:24 <irenab> Hi Bob
13:19:18 <rkukura> hi
13:19:49 <baoli> I'd like to talk about the BPs
13:20:51 <baoli> In addition to Yongli's BP that covers the generic PCI passthrough, we have https://blueprints.launchpad.net/neutron/+spec/ml2-request-vnic-type https://blueprints.launchpad.net/neutron/+spec/pci-passthrough-sriov https://blueprints.launchpad.net/nova/+spec/pci-passthrough-sriov
13:21:51 <irenab> baoli: regarding https://blueprints.launchpad.net/neutron/+spec/ml2-request-vnic-type I will check with rkukura what is needed based on this patch
13:22:01 <irenab> I will do if needed
13:22:34 <baoli> What exactly will be convered by this one?
13:22:40 <irenab> I can take the https://blueprints.launchpad.net/neutron/+spec/pci-passthrough-sriov
13:22:59 <baoli> Let's take it one by one
13:23:08 <irenab> I thought to make separate patches
13:23:20 <irenab> first, for vnic_Type support
13:23:32 <baoli> ok, go ahead
13:23:50 <baoli> is binding:profile covered by this BP?
13:24:25 <irenab> I am  not sure it fits well into profile, but anyway it seems quite separate from PCI details
13:24:47 <irenab> neutron port maybe created before binding
13:24:48 <rkukura> I'm not sure if implementing binding:profile for ML2 should be part of that, or a separate BP.
13:25:32 <irenab> rkukura: sorry, didn't looked at the patch you pushed. Does it cover the output params only?
13:26:22 <rkukura> irenab: Yes, that one is for output params, and I'm now favoring a single binding:vif_details attribute that is used for both VIF security and PCI
13:26:47 <irenab> rkukura: sounds greate.
13:27:12 <irenab> now we need a way to provide input params that I think quite different
13:27:32 <baoli> so ml2-request-vnic-type covers all the mech drivers to support the vnic-type. is this statement accurate?
13:27:34 <irenab> One: vnic_type, Second: PCI device details
13:27:42 <irenab> baoli: yes
13:27:45 <rkukura> Want to get to decisions quickly on replacing binding:capabilities/binding:vif_security with binding:vif_details, and also on which approach for output params to use in ML2
13:28:36 <baoli> irenab, so the second BP covers binding:profile
13:28:42 <rkukura> So why should we not just implement binding:profile in ML2 and use it for all PCI input parameters?
13:28:57 <irenab> baoli: yes
13:29:27 <baoli> rkukura, would binding:profile available for non-ml2 plugins?
13:29:36 <irenab> rkukura: the idea is to implement it for ML2, but I am not sure that vnic_type should be managed via binding:profile
13:29:40 <rkukura> baoli: It already is for some
13:30:17 <rkukura> irenab: I'd like to understand why you aren't sure about making vnic_type a key in binding:profile?
13:30:36 <baoli> rkukura, so the question is would the enhancment for PCI be available for non-ml2 plugins
13:30:43 <irenab> baoli: any plugin that supports binding extenson and inherits PortBindingMixin can add DB table and store profile there
13:31:38 <irenab> baoli: it event adds more reasons to separate these two bp
13:31:48 <baoli> Just trying to understand rkukura's question:why should we not just implement binding:profile in ML2 and use it for all PCI input parameters?
13:32:39 <irenab> rkukura: seems the vnic_type should be managed on plugin level, sine port maybe created and not bound
13:33:07 <rkukura> We certainly can go ahead and implement binding:profile in ML2, similar to what's in the PortBindingMixin I think, but with the bound MechanismDriver able to validate updates once bound.
13:33:07 <irenab> so there will be no Mech Driver to handle it, but the vnic_type should be preserved
13:33:52 <baoli> irenab, I second that
13:33:52 <rkukura> The binding:profile would be persisted by ML2 in its port binding table.
13:34:16 <irenab> rkukura: OK.
13:34:25 <rkukura> binding:profile definitely would have to be preserved before/during/after binding
13:34:45 <rkukura> otherwise it would not be very useful as an input parameter, right?
13:35:00 <irenab> what level will be responsible to "understand" the profile content?
13:35:11 <baoli> so vnic-type is one property in binding:profile?
13:35:36 <rkukura> I'm just suggesting that if the port is bound, the bound MD can reject attempts to update binding:profile if those would invalidate the existing binding.
13:35:45 <irenab> baoli: initialy I thought so, current not sure. But may take it offline to discuss with rkukura
13:36:03 <rkukura> baoli: That's what I've been advocating unless there is a good reason to do otherwise, which I'm happy to be convinced of.
13:36:04 <irenab> rkukura: agree
13:38:25 <baoli> so non-ml2 plugin will check vmic-type in binding:profile to see if it can handle the port?
13:38:58 <rkukura> Are there other input parameters for PCI-passthru/SR-IOV other than vnic_type, and if so, are we agreeing those belong in binding:profile?
13:39:23 <irenab> rkukura: vnic_type is not specific for PCI
13:39:26 <baoli> rkukura, vnic-type is introduced due to SRIOV
13:39:35 <irenab> it maybe virtio/pci/mavtap
13:39:36 <rkukura> baoli: Other plugins are monolithic - they really don't have to choose between multiple ways to bind the port like ML2
13:39:40 <baoli> But it has one value to cover the traditional port
13:40:12 <irenab> rkukure: actually Mellanox plugin already supports two (pci/macvtap)
13:40:17 <baoli> rkukura, I understand that
13:40:51 <irenab> baoli: do you need this to work for Plugin too, not only in scope of ML2?
13:41:25 <rkukura> baoli: So can monolithic plugins simply ignore a vnic_type that happens to be present in binding:profile?
13:41:32 <baoli> irenab, I don't need it now.
13:42:37 <rkukura> If the argument is to make vnic_type a top-level attribute so that all plugins that implement the extension are required to understand/enforce it, then how is this different than other data that may be put into binding:profile?
13:43:13 <irenab> rkukura: in scope of ML2 what flow would you suggest to handle vnic_type across the listed Mech. Drivers?
13:44:07 <irenab> I wanted to avoid changing existing Mech. Drivers
13:44:39 <baoli> rkukura, in my mind binding:profile includes the following info: PCI slot information including vendor_id/product_id, port profileid, pci flavor if any
13:44:55 <rkukura> irenab: Each MD capable of binding would look for vnic_type in binding:profile, and if present, take it into consideration when deciding whether/how to bind.
13:45:27 <baoli> Looks like that we need to take this offline
13:45:42 <baoli> But do we agree that we need a new BP to cover binding:profile?
13:45:56 <rkukura> baoli: That all makes sense to me, and it seems we need binding:profile in ML2 then.
13:46:22 <irenab> baoli: I can rework the already registered for vnic_type
13:46:42 <rkukura> I think this should be a new generic BP for ML2, independent of PCI specific, which I'm happy to write/submit today.
13:46:48 <baoli> rkukura, I'm confused. binding:profile is needed in ML2
13:47:14 <rkukura> baoli: You just convinced me of that, for "PCI slot information including vendor_id/product_id, port profileid, pci flavor if any"
13:47:28 <baoli> rkukura, you made it sound like that i's only needed by ml2
13:47:50 <irenab> so  we have: 1. generic ML2 support for binding:profile - rkukura
13:48:02 <rkukura> So whether we end up putting vnic_type in binding:profile or making it a separate top level attribute, binding:profile needs to be implemented, right?
13:48:14 <irenab> 2. support ML vnic_type
13:48:14 <baoli> rkukura, agreed
13:48:31 <irenab> 3. support PCI slot via profile
13:48:36 <irenab> rkukura: agree
13:48:48 <irenab> all 3 make sense?
13:49:06 <rkukura> irenab: I think so, but not 100% clear on what you mean by "ML" in #2
13:49:09 <baoli> irenab, what is 2?
13:49:43 <irenab> add vnic_type support for binding Mech Drivers in ML2 plugin
13:50:07 <irenab> this is for (2)
13:50:16 <baoli> what is 3?
13:51:01 <irenab> baoli: support for PCI slot info via binding:profile
13:51:02 <rkukura> irenab: I think #2 would cover either of the two options (top-level and binding:profile key), right?
13:51:40 <irenab> rkukua: right, but if you are OK with doing it via profile, it even works without changing neutron client
13:52:22 <irenab> rkukura: in addition to key it should be managed by Mech. Drivers
13:52:52 <baoli> irenab, confused. I thought binding:profile support would include the pci info, therefore a BP to cover it. A BP to cover its use in ML2. And then the question about vnic-type
13:53:07 <rkukura> irenab: "works without changing neutron client" is an advantage. The disadvantage of doing #2 with binding:profile as I understand it is that the value might be ignored rather than enforced by some plugins.
13:53:28 <irenab> rkukura: I think you right
13:54:10 <baoli> rkukura, in that case, does it matter for vnic-type in the top-level or in binding:profile?
13:55:18 <irenab> baoli: for SRIOV we have more one Mech Driver, so thought we need some generic utils/level to deal with common part
13:55:43 <rkukura> I'd like two see two BPs regarding these input port attributes: One generic covering implementing binding:profile in ML2, and one specific to PCI-passthru, defining the vnic-type (wherever it goes) and any keys for binding:profile.
13:55:50 <baoli> irenab, ok
13:56:26 <irenab> rkukura: so you are taking the first one, for generic part?
13:57:35 <rkukura> For ML2, if vnic_type is a key in binding:profile, I think we'd implement code in the AgentMechanismDriver base class that checks to make sure vnic_type is virtio or empty, and not bind if it is anything else.
13:58:00 <rkukura> irenab: I'm happy to take the generic binding:profile implementation for ML2
13:58:03 <irenab> still not sure that need to mix vnic_type with pci, but never mind
13:58:24 <irenab> rkukura: what about not AgentMechDrivers that can bind?
13:58:42 <baoli> time's up. Shall we resume tomorrow?
13:58:54 <rkukura> They should each also look at vnic_type as well
13:58:55 <irenab> baoli: seems so
13:59:09 <rkukura> I can be here tomorrow at the scheduled time
13:59:14 <baoli> ok, sounds good.
13:59:18 <baoli> thanks everyone
13:59:26 <rkukura> bye
13:59:27 <irenab> rkukura: can we chat a little bit to progress with vnic)type/pci?
13:59:45 <baoli> #endmeeting