14:00:48 <sadasu> #startmeeting PCI passthrough
14:00:49 <openstack> Meeting started Wed Dec  4 14:00:48 2013 UTC and is due to finish in 60 minutes.  The chair is sadasu. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:50 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:53 <openstack> The meeting name has been set to 'pci_passthrough'
14:04:57 <sadasu> Is Yongli there?
14:06:09 <sadasu> baoli: are we primarily waiting for Yongli to join?
14:06:25 <baoli> yes, waiting for everyone to join
14:07:34 <irenab> baoli: can you please share the topics for today?
14:08:48 <baoli> @irenab, I'd like to go over the design with Yongli, that's why I changed the meeting time
14:08:58 <sadasu> I think the latest entry in the google doc says that Yongli will not be able to attend
14:10:04 <baoli> we have email communication, and he said he would join
14:10:59 <irenab> baoli: in case Yongli is not going to join in few minutes, may we discuss the neutron related part?
14:11:32 <baoli> absolutely. And I also want to discuss port profile
14:11:46 <irenab> baoli: great
14:12:03 <baoli> Looks like Yongli just joined
14:12:05 <sadasu> Hello Yongli!
14:12:12 <irenab> Hi!
14:12:13 <heyongli> hello
14:12:24 <heyongli> sorry for later,
14:12:31 <sadasu> #topic PCI alias
14:12:39 <baoli> Not sure if Yunhong would join, it's too early for him
14:12:43 <baoli> So let's get started
14:13:45 <heyongli> summary work of me:  split nova bp, coding in the way
14:14:24 <sadasu> how are u splitting nova BP?
14:14:44 <irenab> heyongli: Can you please share the link to blueprints?
14:15:03 <baoli> First of all,device 'class' or 'feature' auto-discovery. Can we do it?
14:15:07 <heyongli> split the database and API for config to stand alone bp which denpd on pci-extra(sriov support)
14:15:46 <heyongli> for now, the featrue auto discovery is hard to push if libvirt can not suppprt it
14:16:12 <baoli> @heyongli, it doesn't have to depend on libvirt
14:16:48 <heyongli> @bali, yeah, but if we want to support it from native linux, there is much hard work to solve
14:17:06 <baoli> Can you describe what it is?
14:18:39 <heyongli> auto discovery plus native linux script is hard push to libvirt of nova i think
14:19:37 <baoli> Well, if we agree it can/should be done, we can create a new BP and get it done by someone
14:19:48 <sadasu> heyongli: what support do you need from libvirt to make auto discovery work?
14:20:24 <heyongli> device-type  or the feature auto discovery by libvirt
14:21:13 <baoli> Well, it doesn't need to use libvirt, right?
14:21:59 <baoli> Any reason that it has to depend on libvirt to provide it?
14:22:34 <heyongli> @baoli, yeah, it's possible by another way, but seems not same style code like current: all come from libvit, but there does some code use native linux facility
14:23:03 <baoli> So, it can be done with native linux support.
14:23:35 <baoli> Shall we vote on that?
14:24:01 <itzikb> @baoli: What is the linux native way?
14:24:04 <heyongli> i'm not againt to support it not by libvirt, and if we want, this is will little bigger work, and we should make it as a further work, or the next step
14:24:54 <heyongli> i mean , in icehouse at least the icehose2, we won't have it
14:25:07 <baoli> @itzikb, we've discussed that we can use information from /sys/class/net and libvirt to find out the type of a pci device
14:26:29 <itzikb> @baoli: I thought that I can find the information from libvirt but I was mistaken
14:26:42 <baoli> Secondly, how to name a pci group. The doc suggested to use the format feature:[name]
14:27:17 <heyongli> why use feature as the key? i think group is straitforward but this is minor
14:27:37 <itzikb> @baoli: Can you please clarify how do you get the information from /sys/class/net ( or refet to a doc) ?
14:28:30 <baoli> @itzikb, I don't have it offhand. But let's discuss it offline
14:28:39 <heyongli> cat /sys/class/net/eth0/address we get :00:1d:7d:d6:f8:f5
14:28:54 <baoli> @heyongli, the idea is that one don't have to provide a group name but use the feautre itself
14:29:21 <irenab> heyongli: we get from the link the PCI address, right?
14:30:01 <heyongli> this is binding to feautre, but this is not nessary , what if you want sub group of a feature, we need group again
14:30:43 <heyongli> @irenab, address in that dir is a regular file
14:31:32 <baoli> @heyongli, what do you think how feature auto discovery will be used?
14:32:00 <heyongli> we should use group for pure group , and after we finished autodiscorvery the feature, the 'feature' can be another group key through the configuration
14:32:32 <heyongli> we don't change anything about group logic in this way
14:33:34 <heyongli> @baoli, you  guy want use feature as a request spec , are you?
14:34:24 <baoli> @heyongli, in some cases, a 'group' doesn't have to be specified
14:34:54 <baoli> Do you want to define predefined features? You said 'group key throught configuration'
14:34:56 <heyongli> i want the group finnally hold the regular express for address
14:35:35 <heyongli> group is the key, and it's value to define the group name, define anythin you want ,this is admin's choice
14:36:18 <heyongli> for now, grouping just use key 'vendor' and 'product'
14:36:28 <baoli> Well, with auto discovery, it makes sense to predefine features.
14:36:53 <heyongli> yeah, when auto discovery done 'feature' key is ready to use
14:37:47 <heyongli> in new config option say pci-group-key you define ['feature'], then device group as feature , is this what you want ?
14:38:43 <baoli> @heyongli, it is in the doc. But we want to know if you agree, or in your mind, how it should be done
14:39:08 <heyongli> group  with 'group' key is much flexable, we support 'group' in first version
14:39:15 <heyongli> then we do feature auto discovery
14:39:39 <heyongli> and then you can use the 'feature' as group key without change the code again
14:42:24 <heyongli> how do you think about this approach , @baoli
14:43:44 <baoli> @heyongli, we can do it in a different phase. Can you modify the doc to clearly describe your approach if there is anyt difference from the doc?
14:43:59 <sadasu> heyongli: and this becomes part of whitelist specified on each compute node
14:44:20 <heyongli> this is make sense for align to the time deadline, and we get flexable way to group, and decouple the grouping itself from feature, this is why i try to persuade you guy do thing in this way
14:44:42 <heyongli> @sadasu, ok i will update the auto discovery feature part
14:45:23 <irenab> heyongli: we just need to keep in mind the work that admin should do and try to minimize it
14:45:31 <heyongli> @sadasu, we want address, then it's local to compute node, but the featue does not must be local
14:45:52 <baoli> @heyongli, please use a different section to describe your approach.
14:46:08 <heyongli> @irenab, minimize what? the config size or keep it not local?
14:46:14 <heyongli> @baoli, sure
14:46:26 <baoli> Ok, let's move on
14:46:37 <heyongli> the group method i updated is clear?
14:46:42 <irenab> heyongly: minimize manual configration operations he need to do
14:47:33 <heyongli> @irenab, yeah, feature can be global it's good thing
14:47:59 <baoli> @heyongli, I am not sure how much difference there is
14:48:03 <sadasu> heyongli: yes. now, with this, what do we need on the controller node?
14:48:43 <heyongli> @sadasu, i'm not clear what you mean, define the featue on controller?
14:49:22 <sadasu> heyongli: is the whitelist on the compute node, the only config file needed now?
14:49:37 <heyongli> @baoli, group and the feature?  i much prefer make group is general way to group, feature is bind to the property of pci device
14:50:15 <heyongli> @sadasu, i should check this, but in my picture it should be(not sure)
14:50:25 <baoli> @heyongli, that's agreed. But we say the group can be denoted as feature:[group]
14:51:09 <heyongli> @baoli, i don't think so, featue as you desc, it's pci's property not for anything
14:51:45 <irenab> heyongli: Do we still need alias definition at Controller and Flavor for SRIOV NIC?
14:51:47 <heyongli> and 'feature' is the key in the spec, group just a value,
14:52:09 <heyongli> @irenab, alias is always needed
14:52:50 <irenab> heyongli: and what about flavor extra_spec?
14:53:01 <heyongli> if remove alias, pci pass-through is totally re designed .
14:53:19 <baoli> @heyongli, I suggest that you come up with a doc that describes how it should be done with your approach.
14:53:32 <baoli> @heyongli, I don't think alias is the key of the current design
14:53:40 <heyongli> @baoli, i had done in a wiki page
14:53:42 <baoli> and implemenation
14:54:11 <baoli> @heyongli, I've read it, but I don't think that it has the details that we need
14:54:11 <irenab> do we want to support NIC hot plug case?
14:54:14 <heyongli> @baoli, if no alias, you need specify a spec with out name
14:54:36 <heyongli> @baoli, what missed? let me add it
14:55:36 <irenab> heyongli: how hot plug will be supported with flavor havinged predefined number of requested PCI devices?
14:55:42 <heyongli> @irenab, what work should be done for hotplug?
14:55:48 <baoli> @heyongli, please post your wiki url so that everyone else can read it. I actually got it from your comments, but not have it offhand
14:56:28 <heyongli> @baoli, my home access that wiki is buggy i will update it to your google doc
14:56:56 <irenab> heyongli: once VM is rnning, you want to attach it aditional SRIOV vNIC. I am not sure, but seems that current approach does not allow it
14:57:46 <heyongli> @irenab, is there support by nova?
14:58:05 <sadasu> @irenab: current approach doesn't support that. Do u need that?
14:58:25 <irenab> heyongli: Yes. I just want to be sure that nova approach regarding PCI passthrough will enable this use case
14:58:43 <heyongli> @irenab, i'm not sure if nova let us do it, i know resize might work but not in a active vm
14:59:49 <heyongli> @irenab, i don't see a way to do that now, i might be wrong, i just don't know
15:00:18 <irenab> heyongli: just wanted to see that going with flavor approach won't eliminate the abbility to add NIC
15:01:22 <heyongli> @yjiang5, what do you know about hotplug?
15:01:25 <irenab> seems the meeting time is over. same time next week?
15:01:43 <yjiang5> hmm, I remember the meeting is UTC15 in the mail?
15:01:45 <heyongli> @irenab, sure
15:01:49 <sadasu> @irenab: You asked for Tuesdays right?
15:02:17 <irenab> sadasu: its preferable, but not must
15:02:20 <heyongli> https://wiki.openstack.org/wiki/PCI_passthrough_SRIOV_support#tracking_device_allocated_to_alias
15:02:25 <heyongli> my design link
15:02:38 <sadasu> #link https://wiki.openstack.org/wiki/PCI_passthrough_SRIOV_support#tracking_device_allocated_to_alias
15:02:47 <sadasu> heyongli: thanks
15:02:56 <sadasu> #endmeeting