13:00:58 <baoli> #startmeeting PCI Passthrough
13:00:59 <openstack> Meeting started Tue Jun 10 13:00:58 2014 UTC and is due to finish in 60 minutes.  The chair is baoli. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:01:00 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:01:02 <openstack> The meeting name has been set to 'pci_passthrough'
13:01:11 <baoli> Hi
13:02:35 <irenab> hi
13:04:07 <irenab> baoli: how is going?
13:04:10 <baoli> irenab: Hi. Hope you had a good time in Paris last week.
13:04:24 <irenab> baoli: thanks, it was great
13:05:15 <irenab> baoli: you did a good job with the spec, it seems quite finished. Now need cores to appove
13:05:39 <baoli> irenab, thanks. I reached out to John a couple of times.
13:05:53 <baoli> I also kept updating it based on comments
13:06:46 <baoli> One comment from Yongli. He still wanted to include product_id/vendor_id in the stats key for sriov networking
13:06:49 <beagles> I've asked Dan Berrange to have a look... Russell is back from pto, so he'll probably be taking a look as well (if he hasn't already)
13:07:05 <baoli> beagles, thanks.
13:07:18 <irenab> baoli: I am still struggeling with neutron pieces of our Md, but hope will upload the code soon, working with your POC code for now.
13:07:24 <baoli> I addressed Dan's comments
13:07:36 <baoli> He seemed to be happy with that
13:07:46 <beagles> cool
13:07:48 <baoli> irenab, cool
13:07:53 <heyongli> hello
13:08:01 <baoli> Yongli, Hi
13:08:14 <irenab> heyongli: hi
13:08:17 <baoli> Yongli, I'd like to discuss your comments in the spec a little bit
13:08:35 <heyongli> sure
13:09:10 <baoli> Yongli, in the spec, I proposed to for tagged entries, use the "tags only' as stats keys. And You wanted to include product_id/vendor_id in the stats key as well.
13:09:36 <baoli> I'd like to hear options from other folks on that.
13:09:49 <heyongli> i wont to block IT. just best to have
13:11:12 <irenab> any idea why bp is now depends on another one: https://blueprints.launchpad.net/nova/+spec/pci-passthrough-sriov (look at the bottom)
13:13:20 <baoli> irenab, do you mean the bottom two reviews?
13:13:23 <heyongli> nfv sub team?
13:13:43 <rpothier> I added the review for this, but I made a mistake and it but two reviews
13:13:56 <baoli> oh, you mean the numa scheduling?
13:14:13 <irenab> baoli: yes
13:14:56 <irenab> does dependedncy means that till numa is not merged it will block pci code to be merged?
13:15:59 <heyongli> I am afraid it is
13:16:55 <irenab> any idea why it requirs bp dependency?
13:18:16 <baoli> It seemed that Adrian added it. We can ask him
13:19:09 <heyongli> should be nvf
13:19:39 <irenab> I am probably missing something here (but went trhough log of the last meeting :-)). It does not seem to be correct to put dependency without discussing it ....
13:19:55 <irenab> by the way NFV is not the only consumer for NFV
13:20:03 <irenab> for SR-IOV
13:20:29 <beagles> I agree, doesn't seem right
13:20:39 <irenab> we must to chat with Adrian to see if its really requires dependency
13:20:54 <baoli> let's send an email to the mailing list
13:21:00 <heyongli> nfv sub team put this spec in its scope
13:21:06 <baoli> asking for clarification
13:21:15 <irenab> baoli: +1
13:22:01 <sadasu> baoli: agreed
13:22:33 <sadasu> if this topic is done I had a few questions for Irena
13:23:01 <irenab> sadasu: sure
13:23:14 <baoli> Ok, so everybody is ok with adding the product_id/vendor_id into the stats key?
13:23:38 <heyongli> good to me
13:24:09 <baoli> all right, let's move on
13:24:11 <irenab> baoli: I didn't see the need when using your POC, but OK with it
13:24:49 <sadasu> baoli: seems like there might be a NUMA is making changes to the scheduling filters for PCI devices
13:25:29 <heyongli> sadsau sound reasonable
13:25:31 <baoli> sadasu, I'm not sure if pci devices are association with particular numa cpu cells.
13:25:35 <sadasu> I just skimmed through their BP, but I have a feeling that baoli's BP and this NUMA BP might be modifying the same areas of code
13:25:40 <baoli> association/associated
13:26:07 <baoli> So we need to understand it. But I don't believe our BP is depending on it.
13:26:35 <irenab> baoli: agree
13:26:54 <heyongli> baoli numa is important to sriov for nfv Sub team
13:26:54 <sadasu> baoli: not sure
13:27:03 <sadasu> here is a line in their BP: The NUMA filter (in development) will be extended to query the nova.pci_devices to check on the permitted NUMA allocation.
13:27:43 <sadasu> ok...so they probably don't worry about the PCI device allocation itself
13:28:07 <sadasu> lets see how it plays out in the ML
13:28:21 <baoli> #action send query to Adrian and mailing list
13:29:04 <sadasu> regarding product_id/vendor_id, how much will it affect baoli's current implementation?
13:29:42 <sadasu> the currect POC code from baoli seems to be doing fine without this change
13:29:50 <heyongli> sadasu i believe its small
13:30:28 <heyongli> sadasu it works but this is best to have
13:30:40 <heyongli> and no big impact
13:30:45 <baoli> sadasu, with them added, a user can allocate the device in a few ways: use product_id/vendor_id in the pci alias, use the physical network tag in the alias, plus the way for SR-IOV networking
13:31:07 <sadasu> ok
13:31:34 <baoli> heyongli, right?
13:32:46 <heyongli> yeah i believe from alias is not the major concern. most of this drive by image constrain
13:33:18 <sadasu> I am testing only the use case where physical network is specified in the tag
13:34:11 <heyongli> that is enough for my understand
13:35:39 <sadasu> other than the UT support that will be provided by baoli, is anyone else testing the other tag types?
13:35:49 <heyongli> from alias allocation not use it as nuetron port
13:36:12 <sadasu> heyongli: agreed
13:36:15 <baoli> Heyongli, I don't think that we have a clear understanding to that requirement yet. But I think it is not a big deal to include them in the stats key. So if you insist, I'll include them, and let's move on.
13:37:12 <heyongli> thanks
13:37:30 <baoli> sadasu, you want to go ahead with your questions?
13:37:30 <sadasu> just wanted to spend a couple of mins to see if this has impact on things other than baoli's coding/UT effort
13:38:35 <sadasu> yes, my question was regarding security groups
13:39:03 <sadasu> with SR-IOV ports  we cannot apply security groups on the host
13:39:21 <sadasu> how are other vendors dealing with this issue?
13:39:31 <irenab> sadasu: I am currently going to declair in MD that not going to support security groups
13:40:20 <sadasu> yes, in the absence of security groups, does your switch that is located on the adapter able to do something like ACLs
13:40:56 <irenab> sadsu: yes, but not the full list of options as can be done with OVS/iptables
13:41:24 <irenab> it will require another iteration to enable what can be done
13:41:29 <sadasu> irenab: can u explain a bit more?
13:42:19 <sadasu> do you mean another iteration of your driver to be able to turn on these features?
13:42:33 <irenab> sadasu: for security groups there is both ingress and egress ACLs, current version of the adapter can do only egress
13:43:00 <sadasu> irenab: ok...thanks for clarifying
13:43:20 <irenab> sadasu: yes, you got my point. It will require another iteration of the MD + agent to support security groups
13:43:40 <baoli> sounds like that we have more work down the road
13:43:45 <sadasu> lack of security group support is raising quite a red flag on my MD
13:43:46 <irenab> and some way to reject unsipported combinations
13:43:52 <sadasu> baoli: +1
13:44:21 <irenab> sadasu: your plans with MD to manage it on switch?
13:44:48 <sadasu> yes, but my MD does not talk to a switch
13:45:11 <sadasu> need to implement it as part of MD for the switch
13:45:21 <sadasu> in the next iteration
13:45:44 <irenab> actually, I thought on some mixture of MDs on for Host side and other for Switch side, but as you said there a  lot of work down the road
13:46:43 <irenab> sadsu: so seems we are alined
13:47:09 <sadasu> irenab: yes.... we are :-)
13:47:27 <sadasu> also there is discussion on support of multi-tenant networks
13:47:44 <sadasu> which we are not supporting again in this release
13:48:08 <sadasu> I would like to add a section on our wiki for future work...and start putting all this there
13:48:14 <irenab> by multi tenant networks what do you mean?
13:48:45 <yongli> lost connection
13:48:55 <irenab> sadasu: +1  for further items on wiki
13:49:23 <baoli> sadasu: +1. please update the existing list on the meeting wiki
13:49:59 <irenab> I think we also must follow the NFV sub-team decisions, to eliminate conflicts and duplications
13:50:03 <sadasu> irenab: multi-segment networks and not multi-tenant networks
13:50:09 <sadasu> baoli: will do
13:50:22 <baoli> irenab, +1.
13:50:34 <sadasu> irenab: +1 about NFV work
13:50:57 <baoli> sadasu, the multi-segment network support (or multi-provider extension) is another further work.
13:51:16 <sadasu> baoli: correct, will also add that to the list
13:51:25 <irenab> sadasu: baoli: agree. We must land some initial code during Juno
13:51:54 <baoli> There are two code reviews posted, which you can find from the BP whtieboard
13:52:15 <irenab> baoli: thanks, saw it today and will start review
13:52:27 <baoli> irenab, thanks!
13:53:01 <sadasu> baoli: cool...will take a look
13:53:41 <baoli> appreciate everyone's time reviewing the patches.
13:54:37 <irenab> any other topics to discuss today?
13:57:14 <baoli> That's all from my side
13:58:00 <irenab> great, thanks. Lets cross fingers to get spec approved by next meeting :-)
13:58:32 <baoli> I need to attend the nova weekly meeting on Thursday
13:59:09 <irenab> baoli: good luck!
13:59:17 <baoli> Thanks everyone. See you next week
13:59:23 <heyongli> bye
13:59:32 <baoli> #endmeeting